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?

That is the patch:

240609.1_AxiDraw.vl (43.7 KB)

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.

1 Like

i don’t have a device to test at hand. but nowadays the patch could look something like this:
AxiDraw-untested.vl (12.5 KB)

does that work/make a difference?


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…

Depends very much on the task.

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.