I’ve been (and still am) resisting adding LEDs to my Lowrider. But, I keep reading things on here about them and I’m not sure how much longer I can resist. To push me over the edge, it needs a little more. Although, Amazon isn’t helping recommending the LED strips to me.
To clarify since I’m still not 100% clear on the terms, WLED is a cool project to control these individually addressable WS2812B LED strips. Adafruit calls these Neopixels.
I think just having a light strip across the bottom of the beam would be good.
I would want it to automatically change color based off the current state. Something like white for Idle, green for Run, yellow for Hold, red for Alarm, etc. Maybe have it blink a color while homing or probing. If running a job, it would be cool to show the lights going across as a progress bar. Or to just show the lights around the current X position.
You might be able to handle automatic Run, Hold, and Alarm colors with the WLED firmware using pins on the Jackpot. Status Outputs | Wiki.js
Has anyone done anything like this?
From a hardware standpoint, it probably makes sense to connect this as a pendant. You would need another ESP32 (or some other microcontroller) to make this happen. That’s a bit outside my comfort zone. I could also make this wireless via a websocket connection (which I’ve played with quite a bit now), but it seems silly to have a second ESP32 so close to the board connected wirelessly, unless you’re already using the expansion slot for a pendant.
I’ve been doing a fair bit of thinking about pendants recently.
I would say these kinds of add-ons probably need to use the websocket interface. The physical part of the FluidDial interconnect is turning out to be messy and poorly implemented from a variety of circuit design points of view.
There probably needs to be some protocol development to add these kinds of interfaces.
With Jackpot as an example, if you have a spindle and a pendant you’ve already used up all available GPIO and UARTs.
One could do a multi-drop serial bus and maybe this is better- but that would also be new development in both hardware and software realms for the FluidNC ecosystem.
Right, I looked at that thread (and linked it in my original post). I’m just looking to do that automatically based on the status string. So, no button presses, no custom gcode.
That’s good to know. I’m not using my FluidDial or a spindle so I have the expansion socket open. I’ve been following some threads where these concerns have been discussed, but they’re way over my head.
Based on my websocket experience, I’m not sure how well that will go since I’ll already be using a websocket connection. I’m specifically using the WebUI v3 websocket port (82 vs 81) so only one connection is active. I may still be able to use the standard port for this purpose which doesn’t auto-close connections when a new one is made. From the FluidNC side, it needs nothing more than the status strings so it may be a non-issue.
If you’re talking about the ESP32 on the Jackpot itself, that is very unlikely to get integrated into the FluidNC firmware even if it’s not difficult.
I’m talking about adding an additional ESP32 to control this, using data from FluidNC. Adding MQTT support to a secondary ESP32 wouldn’t be bad, but doesn’t make sense for my purposes.
I’m just wondering how fluidNC can communicate its status ‘over the air’ for something else, be it wled, mqtt node red or anything else to listen and be able to DO something based on the status updates.
I wonder if for status coming out of FluidNC whether something like a UDP broadcast could be sent periodically with a status packet. Then all your fancy indicators, WLEDs, DROs, etc. could just grab that and listen.
Then for control, (e.g. a pendant or joystick or jog wheel or whatever), use the web socket.
I looked at this when I was constructing a new, more permanent, WLED controller for my LR. I just wasn’t willing to give up 4 GPIO. I think Ryan’s button press method is currently the way to go with a wired connection. I did wonder if there was a way to capture the status the same way the WebUI does, but I never got very far investigating that.
There are plenty of threads on this forum where I feel the same way. We all have our strengths.
If there is anything specific, I’m happy to try and explain. At the same time, I’m only going to be able to teach you to be a programmer about as much as Jonathan is going to teach me to be a boat captain.
No criticism intended - I have come from a place where I didn’t know a fluidnc from a yaml. I still wouldn’t recognise either if I tripped over them, but at least I have an idea what they are now!
I love it when you guys speak dirty, and will happily follow (although that’s the wrong word because there’s a lot I don’t follow!) along, gleaning little bits, and when/if I decide it’s time to dip my toes in to that sea of acronyms I will certainly put my hand up.
Just remember when I do wave , I might actually be drowning!
Same as @bitingmidge I try to follow along the best I can. I would like to learn more about this websocket stuff. I miss having my dust collection automatically triggered on when the spindle starts lol. I had it working with a current clamp, but the thing draws so little current that it would false trigger all the time. Would walk out to the garage and the dust collection would be running just because I left the VFD plugged in and it false triggered, but if I raised the trigger up any more it wouldn’t start when I turned the spindle on lol. So having something else tell it ok turn on and ok turn off would be MUCH better. And that same thing could trigger my servo for the valve as well. But I have no idea where to even start with something like this. Guess I need to just start my own thread and see what all the smart people have to say lol
, I might actually be drowning! 