Yes, on the "queue" tab, click "signal store", and enter a filename. From that point until you click "signal play" (or reset the machine), commands will be written to the filename rather than executed directly.

I'll be honest, I've used this about twice, ever, and it was years ago, so I've no idea if it still works. Give it a shot?

sn

Seems to be ok, and a really cool option. Need that because i replace usb cable by a little bluetooth module, and don't want let my laptop on during drawing. S like you say : signal store ---> signal play ---> exec from store ... except some command not parsed (seems that i've got a transmission pb), all is ok. Really cool, will look at your code for that... And try to find a solution for not parsed comm ... Can i reduce the Bauds for serial com or make it faster than 57600?

...

I never found baudrate to make any kind of speed difference at all.

That message "Comm () not parsed" isn't necessarily something to fix. What it means (if I remember right) is that there's been a "command terminated" character received (ascii 10 - Line Feed LF - https://github.com/euphy/polargraph_server_polarshield/blob/master/polargraph_server_polarshield.ino#L183), but that when it tried to process the command that was terminated, there wasn't actually anything there.

So that happens when you send a ascii 10 without any preceding commands. The command would show up in the parentheses if it really had been received.

I can't quite remember, but it rings a bell - when I was dabbling in zigbee networks, there were spurious CR and LF commands that the wireless comms inserted. At the time, the protocol was a lot more fragile, and it caused chaos. Now it should have no effect.

sn

Anyway, thnx to read and answer to those messages :):):)

will try another BT module tomorrow...