API question

Hello,
I am using the websockets API to control my printer via Python.

I am trying to synchronize an action from the python script with the arrival of the print head at a particular location. My problem is that commands through the server are non-blocking, which means that I have no way of knowing when the head actually reaches its destination.

Running a stateList command on the ws API tells where the print is going to be, not where it is currently, so it does not work to poll this for the information. 

Is there a way via the API of telling whether the printer is completely idle (i.e. not moving) so I can know that the last command completed, and the head is where I want it to be?

Second question: If I execute a GCODE via the websockets API such as M114, the printer returns the location of the extruder to the server. How do I get that message back to my python script?

Thank you for your help!

Comments

  • You never really know where head is since firmware also buffers moves to execute them after moves are send. The only real solution to be sure it is at a position is to flood firmware with 40 M400 commands. When they are all send you know the position is reached. Flooding is needed to overcome any buffering. Only when it is sure firmware executed the line moves have stopped and sending more commands then buffers can hold ensure this. Not nice during prints but when idle for some special test/operations that is no problem. That way we also implemented the snapshot at given position feature.

    Firmware does not allow assigning responses to send commands. There is virtually no hint which line comes from which command. That is why you also get no response on send gcodes. You have 2 choices to get noticed on special responses. In printer-setup->gcode->advanced you can define a regular expression that sends an event when the condition is matched and also includes the first matched group as well as the complete line. That is the easy way - you just listen for that event and do not need anything. The other solution is to enable sending all log responses (there is a filter to limit what gets send) and filter your self for position answers. But that solution is more cpu intensive as you get more then you want, so solution 1 is easier.
  • Thank you. A question along these lines however:

    I apologize because I am new to websockets, but when I do a send of an M400, then do a recv(), I always get back a response immediately of the form: {"callback_id":10586,"data":{},"session":"4D9beRKSgZDItCq&S02i4LKztI!Ufk^v"}. I have tried this with up to 10000 M400s

    If I look at the server gcode window, just like you said, I see the M400 commands actually taking much longer. So, it seems like the server is also buffering them?
  • You always get a response from server for each request, but not all contain data. When you get them that just means server has executed it. In case of M400 send it means it was added to the manual gcode list to be executed. It does not mean that it was already send, so yes it gets buffered internaly. At least our latest firmwares implemented M118 whcih is like M117 just sending the string in response from firmware. I did this as I needed it for a similar case. Send multiple M400. We do not know when they are executed but adding a "M118 marker" allows us to receive a note from firmware that the M400 before are now exected so a following "M114" will report the real position. Guess you need the same trick since you need the feedback to know when it is the coordinate you are waiting for. Or you just take the next coordinate coming if you know the buffered moves do not report it. 
  • This is great. I just updated server and the latest release handles the events correctly. With that I can set a "trap" and catch the event. Thank you!
Sign In or Register to comment.