Has anyone considered a different approach to live updates to the UI that doesn’t involve asking the machine where it is currently at?
Here is one approach that comes to mind.
First, my assumptions. When you send a line to smoothie or GRBL, the response is an immediate ok (if all went well). If you keep sending more lines, eventually the buffer will fill up and the next ok will only happen when that line has been added to the buffer. Assuming that the oldest line in the buffer drops out when that move has been executed, in theory you should be able to determine which lines have actually been executed and the motion for that move has completed?
If my assumptions are correct, you could fill up the buffer and then send the next line and wait for the OK to come back. When that OK comes back, you update the UI for the first move. The next line may not fill up the buffer so keep sending lines until there is a pause again.
Now for the UI animation, taking each lines coordinates and feed rate into account, and using the method outlined above to keep track of which lines have completed, start the animation for the first move as soon as you click the play button and then keep adjusting the animation for each confirmation you receive.
When all the lines have been sent and queued up in the smoothie or GRBL buffer, play out the remaining line’s animations on the screen based on coordinates and feed rate and when its assumed to be complete, turn back on the status requests.
Thoughts?
I don’t mind doing the work, just wanted to get people’s thoughts and to make sure it is in line with the goals for LW first.
I’ll check out the links you posted. And I agree with you and would prefer real updates as well. My tests have shown that it can be a problem for Arduino based systems which is what got me thinking lol.
“Why workaround old tech when new is here, is great and is working”
Cost, which is why smoothie hardware is not in my near future. it is hard to justify spending almost as much on the board as I did my entire system.
There is a growing community of these low end systems that could benefit from Laserweb and my contributions (if any) have been to that end. As long as the LW team is willing to continue to support GRBL, or until my arm is twisted enough that I end up getting a smoothie board lol, I would like to help make this available for them too.
Ok, so my primary focus is the Arduino GRBL based systems but I will continue to help out where I can.
Lol, my whole machine cost $130. Most of these Chinese machines are running Nano clones so replacing one costs about $5-$10. So, going from a $5-$10 Nano to a smoothie is a considerable jump for some.
Even a STM32 nucleo running at 72mhz is only $10 but no GRBL for those yet 
they have the same Nano pin out and if we could get GRBL to work on those then the real time status request would not be an issue.
I have been working through some issues with my laser driver design which is why I have not been able to contribute much so far. Once it is production ready I will be able to help out here more.
oh, I didn’t know I was competing with you LOL.
Yeah, mine was done similarly. The design and all the source has been made available to everyone and I had no intentions on selling it until people asked me to make kits and laser modules available for sale.
Your design is neat looking How much current is it capable of handling?
http://banggood.com
Here is what mine looks like 
I get most of my stuff from DTR laser but I recently scored some NUBM44 6W+ diodes for $75 each so hopefully I will be running a 6W laser soon
On a side note, anyone looking for a laser diode, keep an eye out on DTR’s site for used pulls. The diode in the picture is an M140 2W diode (confirmed 2W with LPM) that I picked up from DTR for $20.
I can’t see the name of the driver IC in the schematic but that footprint looks a lot like the LED2001 that I’m using in my design lol.