Mach 3 is running on the machine which the keyboard is connected to — the response times should be down to the keyboard polling rate, and the latency of the last control signal sent to the machine.
Grbl is less direct — it’s running, self-contained / stand-alone in a black box on the Arduino — while it’s directly controlling the machine, it is in turn being controlled by software on the PC which is drip-feeding commands through a USB connection, into a very small buffer and which is subject to the vagaries of how full that buffer is when one releases the key.
Of course, it would be too much for anyone to try the experiment which I suggested.
My point is, that setup of a job is the place where user interaction in realtime needs to be solid–saving and playing back buffered commands might be informative but doesn’t help the situation.
I put my $20 (each) in buying a stack of the T5720’s and have one running the Tormach and one running my lathe. If I knew how to address the tool-length sensor I’d be running the Nomad with Mach3 too–I briefly ran it with Mach step-and-direction directly to the motor shield back during the motion glitch research last summer. That way I could also use the jog pendant and have a user interface where everything happens on one screen…
Its definitely a Carbide thing,My SO3 is the same…and has been thru 3 different boards. The steps are not even,it could run for 100mm then stagger 3 times within the same distance.
Its not a KB polling issue,I run a PS2 KB and Mouse and the problem persists,it could be the machine/PC connection as that is subjected the crap that is USB.
There are a few USB related issues with this board as it sits so its not beyond the realms of reason.
Carbide 3D really need to ditch USB for this end use tbh,its too damn sensitive.
This behavior is not indicative of a stack overflow. Does anyone have the cache size for any of the Carbide boards?
My point is, the stuttering only happens when using the keyboard / screen interface — if it doesn’t happen when the saved commands are played, therefore the limitation is in the Carbide Motion software (and possibly other comm / control software).
Grbl by default uses 18 steps ahead, when planning, so it shouldn’t be possible in a jogging situation to create a command sequence which will result in the sort of stuttering movement which is observed.
Either try the experiment, explain why it’s invalid, or check w/ the Grbl maintainer, @chamnit
Stuttering can occur with some jogging implementations I’ve seen, but it shouldn’t effect how the machine retains position. It happens when there are a handful of motions in Grbl’s buffer to execute. Since Grbl always ends all buffered motions to a complete stop, Grbl might be more than halfway through the buffer and begin a deceleration phase by the time it receives more jogging motion commands. When it does, it’ll start accelerating again. This is the stutter that you see. Again, it shouldn’t effect position or anything. It’s just a by-product of certain jogging implementations.
My point is, the stuttering only happens when using the keyboard / screen interface
Will, I think we’re strongly arguing the same point–the stuttering is a byproduct of how jogging is implemented. Running gcode is not a problem at all–the Nomad is flawless there (now that the electrical noise problem is sorted out). If I already knew where I was going I’d just enter a G0 line in MDI and be done with it.
Realtime jogging is exactly the one and only situation we’re both talking about. Setting up a job does involve moving an unknown distance while feeling for an edge or whatever during the movement, so it is directly a real-time user interaction.
As it is, I use the continuous jogging to get in the vicinity of the edge, then change to the smallest incremental jog (.001" since I work in inches) and continue. There, I just need to be careful to wait for the machine to move the increment before I hit the button again.
The pausing during continuous jog is just a small annoyance, but to me seems to be the symptom of a problem as you also argue.
Randy. FWIW, I’ve managed to clear out enough space in Grbl v1.0 (still not publicly released) to implement a continuous jogging mode. It also has real-time overrides, which have been surprisingly fun to play with. Hang tight. I’m pushing hard to get this out as soon as I can.
Randy I agree with you. I have run Mach3 for years on a variety of old Windows XP machines and jogging has been smooth as glass.
This has been through the parallel port and both USB and IP Smooth Steppers.
Jack