I proudly own an iDraw A3 pen plotter, which is a more affordable alternative to the Axidraw and appears to be quite similar. Both devices use the EBB command set.
With the vl.Axidraw patch, I have generally been able to communicate with my pen plotter. Sending individual commands works fine, but I encounter issues when trying to send a sequence of commands. Commands get lost, and they are executed randomly and differently each time.
Clearly, something is wrong, but I can’t figure out what the problem is. Does anybody knows what’s wrong here?
The observable concept does not guarantee delivery or the order in which messages are sent. Imagine you have a connection that is owned by a program (COM connection) and the buffer to send can be written at random and the send happens without device acknowledgement. This is a problem, you are working at a very low level.
If your task requires an execution queue, you need to understand if the queue is implemented on the device. Most likely it is not. In fact, it is possible that any new command received by the device will overwrite the one in progress. In this case, the approach in the screenshot is exactly what is causing all the problems you describe.
Then you need to create some sort of ‘engine’ within the application. There are several ways to approach this problem and there is actually a lot of room for creativity. The solution may also depend very much on the task at hand.
Absolutely! That works perfectly! I successfully sent 1600 commands that were executed in the correct sequence and completed. That’s great, I am back on track!
@yar Thanks for the answer; that was indeed the issue. Too many instructions at once were likely overwriting each other. There is now a solution to this—check it out below. I’m not entirely sure why it works, but it does, and that’s what matters. I’ve managed to extend it a bit and now I’m curious about when it might break it again…
I am assuming that the device responds after the command is executed. You could organise a buffer based on SpreadBuilder and send commands from it slowly, sequentially after the device has responded. But it looks like the new ComPort implementation already solves this problem?
But surely your solution solves your specific problem without overcomplicating the application.
@joreg I need to ask one more thing about the patch you shared. It works quite well, as I’m able to send a significant amount of EBB code to the pen plotter without any issues. All commands are executed sequentially. However, some commands are intended to be executed immediately, such as “ES” Stop or “QS” - the current position of the pen. In this case, the behavior is inconsistent. All commands in the queue are executed first, and the commands that should be executed immediately (such as QS and ES) are executed at the end (and not immediately as intended). 240618_AxiDraw.vl (361.3 KB)
hm… not really sure. from what i understand the device has an internal “motion queue” that it adds motion commands to, and “immediate” commands would bypass this queue… so i’d be thinking that it doesn’t require any special handling on vvvv side. wondering if this is a question you could post somewhere on an axidraw… forum?
