repetier
M400 does return immediately
When I send a M400 command, it does return spot on with 'ok 0', even when the the motors are still 'moving' (they aren't moving, they move something). But afaik the M400 command should only return, when it hits the bottom of the stack, or am I missing something? If yes, please tell me and name me an other solution for my problem (namely waiting, until all moves are finished).
Not exactly. It acknowledges the M400 immediately, that is ok. Then firmware waits for end of moves so the next command gets only executed after that. If you have a lcd try M400 M117 After pause
and you should see the lcd text only after moves are finished.
Kind of... I don't have an LCD, sorry for that, but the ack is still comming for the M117 before the move is finished. Do I have any possibility to wait (and for that I mean wait on the pc side) until all moves are finished and get a response after that?
What I am trying to achieve is, move to a certain position and then take a picture. I really must wait, until the move/whatever is finished.
The problem are the send buffers in host and firmware, so if you send M400 and get an ok it is most probably the one send a while ago. So to overcome this problem you can send 10 dummy commands like G4 P1 after it so you can be sure M400 is executed. Then you can execute the foto command.
This was just brought to my attention by a user of OpenPnP.
@repetier, please reconsider.
M400 should only be ok'd once the commands queued before it, are physically done.
OpenPnP drives controllers in an interactive way, using cameras for computer vision, in order to precision-align the electronic parts to be placed on the PCB (among other things). This obviously influences the G-code that is then generated on the fly for placing that part on the PCB. You can't generate a program up front like for e.g. 3D printing.
Obviously the software running on a PC needs a way to know when the motion to hold the electronic part in front of the camera is complete, before the camera is allowed to take a picture for computer vision. Hence we need M400 to behave the correct way. Adding worst-case G4 dwelling is not an option, it has to be fast to be usable.
As the developer who has adapted OpenPnP to many different firmwares, I can say with confidence that all the other firmwares behave that way.
Please fix this. :+1:
_Mark
