Is there an error message API

chrishamm

@stuartofmt When the sequence number increases, query rr_reply instead of rr_model. The messages key is only used by DSF and DWC (internally) but it is not exposed by RRF. You may need to close DWC to get back messages from RRF because they're saved only once per IP address.

stuartofmt

@chrishamm

There may be a bug in ....

Newly rebooted Duet2 3.3RC1

From Computer1 Browser only - nothing else connected to Duet on other computers.

http://[Duet IP]/rr_gcode?gcode=G28 Z

followed by 

http://[Duet IP]/rr_model?flags=f&key=seqs.reply

http://[Duet IP]/rr_gcode?gcode=G28 Z

followed by 

http://[Duet IP]/rr_reply

Works as expected - the sequence number incremented and the error message is returned.

Then:

Testing with DWC on Computer 2:
Send G28 Z from computer 1
DWC "sees" the error message (interestingly it is displayed in bold text whereas if generated from DWC it's normal text).

Computer 1 correctly reports the increment BUT rr_reply stubbornly refuses to provide a response.

Its as if DWC is "consuming" the message on behalf of Computer 2 ??

As an aside - I have found through repeated testing that this is somewhat fragile (at least from a browser). From one computer - (no others running DWC or interfaced to Duet). The G28 Z faithfully increments the sequence count but rr_reply is unreliable - often returning no reply at all. It seems like it is either a timing / race condition ??

A similar experience when using rr_reply on Computer 2 (not running DWC) - using G28 Z on computer 1 -- sometimes Computer 2 sees the reply, sometimes not. In ALL instances seqs.reply is incremented as expected.

chrishamm

@stuartofmt HTTP sessions time out relatively quickly - you must keep requesting rr_status within 8 second intervals, else RRF will think the HTTP session is gone and throw away the G-code response as soon as the last client has got it.

At present you cannot have two HTTP clients requesting rr_reply from the same IP address. As long as your custom session is actively maintained from the second machine (with only one active client), it should work as expected.

stuartofmt

@chrishamm said in Is there an error message API:

you must keep requesting rr_status within 8 second intervals

Thanks for persevering with this.

I still think there is something wrong or I just don't get it or there is something nuanced or my expectations of the behavior are out of kilter ....

Here is a video showing the problem. The two windows are different machines each with a single browser instance. DWC is not running anywhere nor is there anything connecting to Duet other than the two browsers.

I'd expect to be able to get rr_reply consistently from both machines.

https://drive.google.com/file/d/1w4YvY5QSFZWrdZ6-jHy98U7_G00HwkOw/view?usp=sharing

As an aside - the 8 sec window suggests any program polling Duet needs to do so at least ~ every 6 or 7 seconds. For a basic monitor looking to send email notifications - this frequency is way shorter than it needs to be (in general) . Not a problem for the machines themselves of course - but with several programs all polling Duet for different reasons - could this cause excessive load on Duet ? I understand that this type of use was likely not in the original design idea but mentioning it just in case it adds to some inspiration

chrishamm

@stuartofmt I'm sorry but I get an error message when I try to watch that video. For the sake of completeness I launched two independent DWC sessions and I can confirm rr_reply works as expected in standalone mode after sending M118 P3 S"foobar"

from my Windows machine:

and from my Linux machine (with a different IP address):

Obviously the Linux machine cannot map replies to the source G-code but as you can see the message is received by both devices.

Also note that 8 seconds is the maximum timeout value, DWC requests status updates more frequently (at least once per second). M122 reports the current number of HTTP sessions as well (up to 8 ) and G-code replies are cached once per HTTP session. Of course it would be nicer to keep replies longer but then we would risk running out of RAM, so that would be no good option either.

stuartofmt

@chrishamm said in Is there an error message API:

but as you can see the message is received by both devices.

I get the same behavior as you when its DWC is on both machines BUT not otherwise.

Using DWC on my windows machine and just using rr_reply in browser on Linux (and vice versa) ... the responses from rr_reply are hit and miss

I am well within 8 seconds.

Extremely brief demo attached (NEEDS TO BE RENAMED .mp4) - hopefully you can view this format.

rr_reply.txt

EDIT: about 1 in 10 attempts gets a response from rr_reply.

chrishamm

@stuartofmt Make sure that your VM does not use NAT and that it gets its own IP address from your network. If you have NAT enabled, both rr_reply queries will appear to come from the same IP address which would explain your hit&miss. Does M122 show that you have two HTTP sessions when you have your script and DWC running?

I just tested it on my Linux machine, this time with curl and it worked well again:

while [ true ]; do curl http://192.168.1.151/rr_reply; sleep 1; done

That script outputs all the messages without problems. Note that each HTTP request refreshes the HTTP session timers too, so calling rr_reply without previous rr_model requests should work too. DWC just uses rr_model -> seqs.reply to determine when it's time to fetch new replies.

MintyTrebor

@stuartofmt I had to deal with this when I wrote NodeDSF - To get the expected behaviour you are asking for I had to use the rr_connect command (with password and date/time) to establish a session first. Only after establishing a session this way would the system keep track of the responses it has transmitted since the last status/update info request... (you may already be doing this but I couldn't see it mentioned anywhere).

stuartofmt

@mintytrebor said in Is there an error message API:

I had to use the rr_connect command

Thx - I have it working now (see post on traps for young players). Did not need to use rr_connect

stuartofmt

@chrishamm

Problem solved under the heading of "traps for young players"

It seems that the browser is "consuming" the rr_reply but not always displaying it. The prior tests were on physically separate machines (no vm) with distinct (and static) ip addresses. M122 showed two connections.

When I tried this in code - it worked just fine. So basically - testing the API in a browser does not always work.

Another observation M118 is incrementing the seqs.reply counter by 2. M117 and general errors increment by 1 (as expected). Obviously not a biggie but thought you may want to know.

Thanks for your help in wrestling this to the ground.

Edit: For anyone visiting this topic later on. rr_reply returns a new line character '\n' when there is no message.