Yea, if you start a thread I bet something can be sorted out whether that’s websocket or something else. I do think a websocket could help with this. My approach would involve putting code on an ESP32 but maybe some node red or home assistant type thing could help too (I know very little about that).
The short websocket answer is that status string has the spindle speed.
<Jog|MPos:5.860,10.900,0.000|FS:1160,0>
That “FS:1160,0” part means that the feedrate is 1160 mm/min and the spindle speed is 0. So, by monitoring the spindle speed you could determine if the dust collector should be turned on. How exactly you accomplish that from an electronics side, I’m not sure (not my area of expertise). I’d imagine it could be used to trigger a relay.
That’s a great find. That is doing it wired to the board via UART instead of via websocket. It wouldn’t take much to modify that to do what I want. At least if I can resist the developer urge to rewrite everything myself from scratch.
I am glad you think so. I just jumped through and was almost sorry i posted it. I did not see anything about getting it working! But it does look like it is already built! If you can figure it out!
In fact grbl-io seems dead, no contributions in the last year!
Its on the 220v power into the VFD. When doing a normal cut its barely even pulling 1 amp. At idle no cut its like .18 amps. The VFD powered up with the spindle off is .1 That little gap makes it false trigger bad.
Addressable LEDs are not that much more expensive (if at all) than an RGB 12V strip. And you still need some power drivers for the 12V strip. That said, a long time ago I bought some H801 controllers and they work fine for controlling 12V LED strips. I converted mine to addressable RGBs:
As for the control. Can you make fluid call a REST api when the state changes? I have some smart switches that can control other devices without using Home Assistant by just setting up the REST call when a state changes.
Parsing the UART seems like overkill when you have the esp on your wifi and the changes happen on the minutes time scale.
That was my plan to use addressable LEDs like WS2812B strips.
Are we still talking about LEDs or about dust collection?
As far as I know, FluidNC itself doesn’t have any functionality to do such a thing and I would not expect the devs to be willing to add/support such a feature. With a separate ESP32 monitoring the status, absolutely, but at that point I don’t know why I wouldn’t use that ESP32 to control the LEDs directly.
Not sure what it means to parse the UART, unless you’re referring to the GRBL status string.
This seems (to me) to lead towards RGB 12V LEDs. Woth separate leads for R G B channels that you can PWM with some solid state LED drivers. So my first point was that addressable LEDs would be easier, even if you change them all at the same time.
LEDs.
Maybe I missed something. But the solution seems to wire another micro to the UART to read the status string. That seems silly since everything is on the same network. Not wrong. Just overkill. I agree that adding something like that is an uphill battle.
Ok, that makes sense. I have done absolutely zero with LEDs up to this point. I know just enough to be dangerous.
The Github repo that Mike found was connecting another micro to the UART. Based on my familiarity with websockets on an ESP32 and MakerJim’s suggestion to avoid the UART, I was going to go the websocket route anyway. So, I’d just hook up the LED strip to that secondary ESP32 (which is still parsing the status string) and control it with the Adafruit NeoPixel library. If I need a separate ESP32 or some other LED controller either way, I guess that’s about as good as we can do.
There is nothing about any of this that isn’t overkill.
I have an LED strip working with Prismatik and ab Arduino Nano on my monitor for backlight/ambilight, maybe there is some insight to be gained about addressable LEDs?
You could add something to the javascript that would make a REST call from the web client when the state changes. That would avoid making the fluidMC do any extra work or even opening a second websocket for LEDs. It would fail if the browser stopped the script or closed the web socket.
This could be done as a WebUI v3 extension but I don’t like that because it would be dependent on the WebUI being open which I don’t usually do. It also wouldn’t work on WebUI v2.
I once worked with an embedded system that could only accept a single socket connection and which I needed to interface several controllers/monitors to.
What we ended up doing was writing a software mux.
We created a small daemon that would connect to the embedded target, and then allow other socket connections to be made to the daemon.
We had one socket port for command and one socket port for telemetry exposed from the daemon.
The command socket would allow the additional clients to connect and send commands, which the daemon would interleave and time space before forwarding to the embedded target- so the embedded target wouldn’t get confused.
The telemetry socket would take any responses from the embedded target and send them to all connected telemetry socket clients.
This allowed an arbitrary number of remote systems to make use of a relatively fragile and skiddish embedded target.
Oh boy. So, that’s basically making some kind of gateway or reverse proxy. I can understand how such a thing might be implemented, but that’s way further than I’m willing to go to put LEDs on my Lowrider.
I need to do some more work on my other project first, then I’ll try out a proof of concept with a separate ESP32 making a websocket connection. My other project at least showed me that if I use the websocket port created for WebUI v3, it automatically disconnects when another connection is made. That is 100% fine and valid for that purpose. What I need to find out is if I can simultaneously have more than one websocket connection open at the same time if they’re on different ports. Hmm, now that I typed that out I could test this easily by trying to run WebUI v2 and my other project screen thing at the same time.
