replicatorg - Sprinter Buffer issues
Posted by platsch
|
replicatorg - Sprinter Buffer issues November 14, 2011 07:17AM |
Registered: 12 years ago Posts: 2 |
I'm using ReplicatorG to run my reprap, with a standard atmega/ramps 1.2 electronic on client side. The firmware is the last version of Kliments Sprinter.
The communication between ReplicatorG and Sprinter seems to be synchronous, that means: ReplicatorG waits for the "ok" before it sends a new command. Sprinter acknowledges only after finishing the current command. If I manually send some commands without waiting for an ack, everthing's ok, i recieve a bunch of "ok"s directly after the current move.
ReplicatorG always waits for an ok and therfore makes the firmware-buffer useless. The ReplicatorG driver is reprap5d but i've tried some others with the same/similar effect.
I could write a new driver to solve this, but as it seems to be a common problem, I assume i've done something wrong.
Anyone who knows how this should work? are my assumptions correct? Is there a known solution?
The communication between ReplicatorG and Sprinter seems to be synchronous, that means: ReplicatorG waits for the "ok" before it sends a new command. Sprinter acknowledges only after finishing the current command. If I manually send some commands without waiting for an ack, everthing's ok, i recieve a bunch of "ok"s directly after the current move.
ReplicatorG always waits for an ok and therfore makes the firmware-buffer useless. The ReplicatorG driver is reprap5d but i've tried some others with the same/similar effect.
I could write a new driver to solve this, but as it seems to be a common problem, I assume i've done something wrong.
Anyone who knows how this should work? are my assumptions correct? Is there a known solution?
|
Re: replicatorg - Sprinter Buffer issues November 15, 2011 06:07AM |
Registered: 13 years ago Posts: 7,616 |
Quote
I could write a new driver to solve this
Please don't. There are so many firmware projects already.
Quote
Anyone who knows how this should work?
Well, the "ok" should be sent as soon as the command line is received - independent of wether another movement is in progress or not. At least with Teacup, this works fine. The movement queue fills as fast as possible over the serial line. That said, USB-TTL converters have a serious delay, so you end up with only 2 to 5 lines per second if you wait for the "ok".
| Generation 7 Electronics | Teacup Firmware | RepRap DIY |
|
Re: replicatorg - Sprinter Buffer issues November 15, 2011 04:15PM |
Registered: 12 years ago Posts: 2 |
Quote
Please don't. There are so many firmware projects already.
don't worry, i spoke about a ReplicatorG driver, not a new firmware project, and I expected to find an existing solution.
Quote
Well, the "ok" should be sent as soon as the command line is received - independent of wether another movement is in progress or not.
Ok, that's what I found ReplicatorG expects. Sprinter sends "ok"s only after finishing the recent movement. It doesn't use interrupts but reads the next n commands from the UART buffer in the main loop. I wondered whether they are just incompatible in this aspect or if I did something wrong. Thank you for the hint, I'll give teacup a try.
Anyone who uses ReplicatorG and sprinter? how do you handle this?
Sorry, only registered users may post in this forum.