@phaedrux said in Stall detection to detect crash while probing?:
And when you're homing, you're using all 3 motors at the same time
In order for a stall to be detected, I need all 3 motors to stall at once - it won't error out if just one of my z motors stalls out?
I definitely have been stopping 1 lead screw sharply enough that it should detect a stall (turned current WAY down so it's easy to hold) but if all 3 need to stall for it to be detected, that would explain a lot.
thanks.
I'm running a Railcore2. It seems one of the biggest sources of crashes (and crash anxiety) is users who have some sort of z-probing failure. Generally because they left something on the print bed, but sometimes due to wiring failures.
It seems like it should be possible to modify homez.g such that:
A couple of us have messed with every variation on M915 we could come up with and have yet to get the machine to react to it. It seems like: M915 Z S3 R2 followed by G91 G0 Z5 F250 should trigger a pause if I hold one of my z-leadscrews, but nothing happens.
Thanks for any help. Being able to detect this type of error would be a huge safety win for these printers.
@danal said in New M-code to send a network request:
MQTT: Where would the broker be in a typical 3D Printer scenario?
The various discussions of "One HTTP request" and a parameter to wait for a response or not... that all sounds right.
Mine's on my NAS, but you can run that anywhere, or use a public one in the cloud.
@frank26080115 said in New M-code to send a network request:
It should be one GET request and no keepalive. Reply optional. Blocking with a short timeout. Single instance at a time.
I agree, the duet should do nothing to process a response. I would envision we might want a parameter for the m-code to specify a timeout and/or pause (depending on whether this was HTTP or MQTT), though, rather than trying to pick a universal default for everyone.
I should know when I generate g-code that I need to stay put for up to a couple seconds for a picture, or if I'm just sending something "fire and forget"
@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.
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.
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:
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!
Thanks @chrishamm for posting the source!
To pile on to @natewalck's idea - besides the extruder choice, there are several variations among Railcore builds that would be great to capture with a simple radio button or select.
For example, 250mm vs 300mm build dimensions is a change that's trivial to capture and adjust for, but critically important to have propagate several places. Most self-sourced builds use 0.9 degree steppers, while kits use 1.8. etc.
Figured I'd throw in a few more examples of uses since you're already thinking of rewriting the configurator.