Best posts made by lostapathy

It would be great if we could have an M-code that would allow us to send a network request to another machine on the network. Use cases would be:

• Triggering another machine to take an image for a timelapse
• Triggering an alert when a print is finished/cooled off/faulted
• Trigger an alert for manual filament change
• etc

I think we could do this via either via http or mqtt. http is probably a more mainstream option, but mqtt is perhaps a lighter-weight option to consider.

The ideal M-code would take both a destination (http url or mqtt topic) as well as a string payload. I think it would be fine to limit the payload to a static string - the remote endpoint could then call back to the existing API to get whatever data it needs.

I am definitely interested in helping to implement this, but figured it best to check in for strategy guidance before I go too deep.

thanks!

Yes - I am familiar with watching telnet, and also know that people are hooking up outputs on the duet to a gpio pin on a raspberry pi to hook something similar to this up. I'm not a huge fan of needing to scab a pi into my printer just so I can use it for one gpio pin, nor does it seem like a great idea to turn telnet on just so you can watch what's going on.

Modifying DWC to handle something like this is definitely possible, but relies on a running browser which is less than ideal, especially as browsers continue to get more aggressive about sleeping tabs that are not in focus.

All seem like fairly specific and roundabout solutions, though, whereas sending an http or mqtt message out are very general purpose solutions that are common among connected/IoT type devices.

Allowing the duet to push events, rather than relying on external processes to watch, would also scale better in a multi-device environment.

@danal said in New M-code to send a network request:

How about UDP? Keep it simple. "M xxx (resolvable name|ip|broadcast) payload" where the payload is limited to an ASCII string that fits normal Gcode syntax rules (including future Duet/RepRap only extensions for symbolics, etc. ).

I offered the option of MQTT as a lighter alternative to HTTP. It's a super light protocol, comparatively, and since it's common among IoT devices, we wouldn't be plowing new ground with it. I think it's important in matters like this to adopt existing protocols where we can, rather than devising our own UDP protocol. If I wanted to run another bespoke service to collect events, I'd just connect over telnet and watch the stream, after all.

Already, there's a lot of esp8266-based devices that send out MQTTT telemetry, so it's obviously well within reach of the device horsepower, and example code should exist.