This probably isn’t the right place for my question, but I’m not sure where else to start.
I’m using the v3 web UI 3.0.0-3b1-FluidNC - Firmware is FluidNC 3.9.4
It would really be helpful for the message emitted with an M0 command to remain visible in the Status panel until I hit the Resume button. Especially when the next thing that happens after an M0 is to turn on the spindle - I don’t want to accidentally have the probe attached when that happens!
I did a screen recording with a simple test gcode program and captured some frames to show here. The gcode I ran is
M0 (MSG This is a message emitted with an M0)
M0 (MSG And this is another message)
M30
After pressing the Run button on the uploaded gcode file, I see
So, if this isn’t the right place for my question, can someone point me in the right direction? Or, if it is the right place, let me know how I can help get involved with the UI development to make this change happen!
The Status in this area only reports whatever status is being returned to the UI from the firmware. M0 is just an informational message, and does not set it to a certain state.
The Terminal is, well, just a terminal, so as new info messages come in, it will scroll off. This can somewhat be controlled by how often you have updates coming, but there’s not much there that can be done.
This, unfortunately, is the world we live in where the UI and the firmware are developed in a completely disconnected way.
This is likely going to be your best option for what you want
@jeyeager - thanks for that link, it looks like something that might be good enough for what I need.
I did notice, however, when running my little test gcode from my original post that I only get a modal popup for the first M0 and not for the second one. Oddly, a popup with the second message does appear if I hit the “Hold” (Pause button). So that’s a little bit strange. I can make a screen recording of it if you’d like to see – or you could probably test locally with the gcode I posted above if you’re so inclined.
I’m not surprised by that behavior. The extension is just parsing the same data as the terminal. The M0 and the message aren’t actually associated with each other so all it’s doing is keeping track of the last message. When a hold occurs, it displays the last message. The reason it showed the second message when you hit pause again is because that was the last message. It didn’t pick up that second pause because based on the info received, it never went out of a hold status.
I’m open to suggestions but this is the best I could come up with at the time working within those limitations.
I added a few positioning commands between the two messages and it definitely pops up the second message once it has noticed the state change. So that may just be a minor limitation.
I may tinker around with your code when I get some time. Did some initial debugging but it’ll take a while for me to get my head around how everything flows with respect to the message events. (And I’m a backend guy, not a web developer, so I’m already a little bit hobbled… )
Yea, I mostly do backend stuff these days myself. Feel free to submit a PR or ask questions.
Depending on how far down the FluidNC WebUI dev rabbit hole you want to go, here are my notes and links. You probably don’t need the dev server for this.
Just to follow up after I’ve been using your extension for a while – it works perfectly well as-is for my purposes; I just tweaked my postprocessor to combine a couple of messages that were emitted in close proximity into a single message (“load tool x and attach probe”) and it’s working out great.
)