RR_reply and echo



  • When I run gcodes through the API, they go into the buffer, and then they come back in the execution order (I think), but I don't really have any way to know which call generated which response.

    Like if I am checking for a command to finish or trigger some event somewhere in a pin, the order of the events is important.

    I was trying to use M117 for this since, in theory, it returns back your message as echo if there is not an LCD.

    Then I discovered, that it indeed it generates a rr_reply but there is no content on it, the UI is getting the response through a weird
    rr_model?flags=d99fn
    rr_model?key=state&flags=d99vn

    I don't think I fully understand the architecture of the message system, or I am trying to ask too much from it. Is there any extra documentation I could read?

    I moved the automation into a different hardware interface, so the duet 3 will not delete the buffer, but the UI also echos every command I run there, killing the UI with messages.

    For me, I just need M117 to reply back on rr_reply or having an echo message that gets into the pipeline and I will put a timestamp/mark there so I can parse the responses in an event queue, instead of a regex expression that is trying to figure out how many times I've seen this message.

    The current communication system is not very ideal for having machine 2 machine communication at the moment.

    Are there any plans for having a different API?



  • Here you can find my tests to talk to the Duet using Python 3 and a Duet 2 running version 3.11 and a Duet 3.
    https://github.com/triditive/duet_test/blob/master/duet_python_test.py


Log in to reply