Http Post in Macro?
-
I'm no RRF pro, but I do think this should be possible just based on the capability of the duet. Now that I've got a filament sensor that pauses my print, I need a way to know it happened! The beep gcode is cool, but I'll only hear it if I'm close enough to see the print stop anyway.
I do have a lot of smart home stuff including some chimes and sirens that could be triggered via an http command, if I could have my pause.g ping a url. Is that possible? If not, can I pull some unused 5v pin high somehow? I could use an 8266 to detect the pin going hot and notify me, but it does seem unnecessary to use a second internet connected Arduino/board to tell me when the first internet connected Arduino/board has 5v on a pin.
Thoughts?
-
no go on http requests unless using a duet 3 with a raspberry pi - and even then its a custom job.
you could perhaps go the other way, connect from your server to the duet on telnet and use M118 or M117 to send a message your telnet client can listen for.
-
@bearer really!? That's so surprising to me, the duet is obviously already connected to the network and sharing data all over the place. I can't believe I can't throw in a "hey, ping this site when you see this gcode" somehow.
I'm so so with Arduino but rrf is probably above my capability. Surely there would be a simple way to update the firmware to do this? (For someone who knows what they're doing)
-
not sure thats likely to be a priority, it's been brought up before, but you can try https://forum.duet3d.com/category/8/firmware-wishlist
-
This is a totally off-the-cuff thought and implementation (and details) are left as an exercise to the reader ....
The Duet spits out a stream of information via it's USB port. Feed that stream to a micro controller such as an ESP8266 that is running Node Red and Node Red can then talk to your IOT devices.
It's been eons since I played with Node Red so I am fuzzy on a number of things - the Node Red may have to be run on another SBC or available computer but the overall concept of intercepting the console messages is a valid approach and Node Red makes the interface and sending the http or email message trivial. -
-
Rethinking the original question, you don't need to even go that far - just monitor the filament out sensor directly with the ESP8266 ... no need to parse the console stream.
-
The entire philosophy of networking built into Duet/RepRap Firmware as supplied by Duet, or if you prefer, Dave, is that things query it (perhaps repetitively, i.e. 'poll'); it does not push. To my knowledge, this has never been stated anywhere; nonetheless, it is quite clear if you look at how it works, and what feature requests have been implemented, and not, over the years.
DSF on the Pi offers an opportunity to change that, without changing the underlying Firmware and/or DSF. There is an explicit intercept API that can be used from almost any language:
https://github.com/chrishamm/DuetSoftwareFramework#interception-mode
-
For the original use case, "intercept" and then look for something unique to the pause.g, up to and including an M117 with a specific string in the message.
When detected, you can then do anything a Pi can do... which is incredibly flexible.
-
@clearlynotstef said in Http Post in Macro?:
the duet is obviously already connected to the network and sharing data all over the place.
btw, thats not quite true. the only thing the duet sends out is dhcp requests and mdns in the versions where that is supported; everything else is initiated from a client afaik.
-
@bearer said in Http Post in Macro?:
@clearlynotstef said in Http Post in Macro?:
the duet is obviously already connected to the network and sharing data all over the place.
btw, thats not quite true. the only thing the duet sends out is dhcp requests and mdns in the versions where that is supported; everything else is initiated from a client afaik.
Exactly. For whatever reason, it doesn't originate any TCP connections. (both dhcp and mdns are UDP or UPD-like, anyway, no actual connection). It expects to be polled.
-
I've got an m42 in pause.g flipping a gpio pin connected to an 8266 which handles the http get which notifies me different ways based on where I am or what I'm doing. Next question. Can I have the Filament monitor call a different macro than pause.g? I'd still like to occasionally pause my print with the pause button without setting these events in motion. Related second question, can I run a macro from within a second macro? The most efficient thing would be to have the Filament monitor run filamentout.g which would consist of the m42+run pause.g so updates to pause.G would apply to both but I'd still be able to pause manually without notifying myself.
-
@clearlynotstef said in Http Post in Macro?:
Can I have the Filament monitor call a different macro than pause.g?
not without making changes to the firmware afaik.
but you can connect the filament monitor to the esp and have the esp execute M98 filamentmonitor.g over http/telnet/serial.
-
@clearlynotstef said in Http Post in Macro?:
can I run a macro from within a second macro?
Yes. M98 p"/sys/macro.g" or p"/macros/macro.g"
Can I have the Filament monitor call a different macro than pause.g
Not if it is set up as the filament monitor.
However, if you connect the hardware filament monitor to a GPIO pin and set a trigger, that trigger can pause, and do anything else you can do from a macro.
-
Was going to make a new thread but I guess let's keep this all in here. Does anyone know if the extra gpio pins that can be M42'd are pulled down if switched off (S0) or if they're just floating? Based on my printer paused notification I just got even though I'm not printing anything, I'm assuming it's floating?
-
If it is the correct pin, which is sometimes very hard to figure out what's what, a M42 S0 should cause it to pull down. It would be capable of sinking current up to the spec of the chip, usually under 20ma.
Delta / Kossel printer fanatic
-
@Danal that's surprising! Floating would have explained everything. I'm pretty positive it's the right pin, and I did test it 5 or 6 times in a row, S0 to s1 back and forth and watching the notifications track perfectly. I guess I'll throw a 10k resistor from gnd on the esp8266 to the input pin on the esp8266 and see if that helps? I'm no electrical engineer over here lol
-
It can sink or source 2mA, 4mA on a few select pins; (20mA is for the 8bit chips like attiny/atmega)
Some pins have pull up/downs in hardware, others configured in firmware; gotta check schematics and config to be sure.
-
@bearer said in Http Post in Macro?:
It can sink or source 2mA, 4mA on a few select pins; (20mA is for the 8bit chips like attiny/atmega)
Some pins have pull up/downs in hardware, others configured in firmware; gotta check schematics and config to be sure.
WOW, good to know!!!
-
@clearlynotstef said in Http Post in Macro?:
@Danal that's surprising! Floating would have explained everything. I'm pretty positive it's the right pin, and I did test it 5 or 6 times in a row, S0 to s1 back and forth and watching the notifications track perfectly. I guess I'll throw a 10k resistor from gnd on the esp8266 to the input pin on the esp8266 and see if that helps? I'm no electrical engineer over here lol
Approx 70K to 130K, nominal 100K is what the SAM4E series does internally for pull up or down, so I'd just copy that.
-
@bearer I'm using duet2 WiFi, pin CS5, logical pin 60, expansion header pin 50. Any idea?
-
