Dead time between G1 commands over USB
-
Hi everyone,
I didn't find an answer to this question in the docs, but I was wondering if there is a little time where a stepper doesnt move between 2 G1 move commands.I am trying to move my motors for specific distances within a very precise amount of time, ex: 2cm in 1.5 sec, and then I do back and forths with my motor (sending repeatedly the same G1 command but inverting the direction, ex: G1 X10, G1 X-10 infinitely).
I realise that I always get about a 3% error margin (the motor moves 3% too slow) . *I did correct for the acceleration of my motor and for the wasted dispacement during the accel and decel periods (and increased the feedrate accordingly), based on my max acceleration setup with the M201 command.
I was wondering if I get this 3% slower move because of an automatic dead time between commands, maybe a couple milliseconds to process a command? Otherwise, would anyone have an idea of what could be causing this lag?
Thanks a lot!
-
How are the commands being sent?
-
@Phaedrux They are sent with a command line script in c++ that generates strings and send them to the duet3d via a serial com port. I tried sending a bunch of commands at once but there still was a 3% lag.
Something interesting though is I tried using the command M114 (get motor pos) and I needed to wait a few milliseconds before reading my data buffer from my com port, otherwise the response from the Duet3D was not received yet. Looks like data exchange between the pc and the duet is very slow, but I dont know where the delay is coming from.. Either the Duet or the PC.
-
@dc42 would have to explain in depth, but yes there will be some fundamental differences between reading commands from the internal SD card during a print and executing sequential gcodes over USB.
-
@Phaedrux Good to know! And the difference makes it faster to execute from sd card or usb?
-
@jcsb1994 The Firmware has a buffer that it fills - if you are only sending one command at a time then that would eman a delay while the move was processed. A good test would be to compare the test with the commands written to a file on the SD card vs streamed over USB and see what you see.
It is not that SD is faster specifically in this situation - both are theoretically fast enough if you are doing 10mm straight line moves on a "normal" printer - its the ability for the firmware to processes the moves and string them together.
-
@jcsb1994 said in Dead time between G1 commands over USB:
I am trying to move my motors for specific distances within a very precise amount of time, ex: 2cm in 1.5 sec, and then I do back and forths with my motor (sending repeatedly the same G1 command but inverting the direction, ex: G1 X10, G1 X-10 infinitely).
If you send those commands as a block, then there should be no gaps between then, just the acceleration and deceleration at the start and end of each move.
Please provide the calculations you have done that lead to think that the movement is 3% too slow.
