Sorry it is a bit messy. look at the word “engineering” at the bottom of each letter. There is zero accelerations happening and it is slamming. The difference between them is Junction deviation set to 0.2, 0.016, 0.008, 0.002. There seemed to be zero difference between them. The accels for that in general do not seem right. If you look at the concentric circles, the smallest two run stupid fast, the rest seem to have accels happening.
This test file ran like actual dog poop on 414, almost perfect on the 415. If you run it I have the pen offset the thickness of a paper business card when I hit start. Arc Torture test.gcode (24.8 KB) Arc Torture test.zip (20.4 KB)
With JD still on, I tried with no S curve, then with no adaptive…no change. I then tried Classic Jerk at 1,1,0.3, great…a bit too slow though. Went up to 5,5,0.3 small details were flawless, I mean just how you want to see it move, but as the moves got larger it would almost speed up slow down and speed up again, super wonky. So on the concentric circles the first three were great but the next three would have that weird arc issue almost but would instead accel and decel twice per circle.
Okay after a ton of brute force attempts and trials. I like 230 for accels and a JD of 0.045, still not convinced of this thing working but that is the calc.
I swear there is a (-) sign missing from the junction deviation equations or something. Smaller radius are most certainly accelerating faster and larger ones are much slower.
I’m looking for like a way to see what the output of marlin is doing with the Gcode. After it goes through the plannner. I do not think JD is working right, but I also think If I could see the output I could get it real close and accurate instead of my current, edit, compile, flash, run, test cycle.
Setting the JD to .2 all the way down to .002 seemed no different at all in any way. I can tune the regular jerk and accelerations much more confidently.
Seeing the planner output is something I’ve wanted before too. When I increase the joystick position from slow to fast, it will momentarily slow down and then speed up. I am pretty confident my movement commands are not doing that, and I have no visibility into why the planner is doing that.
It looks like the simulation machine is to compile the thing as a Linux program and it looks like you can log the position trajectory over time. You would have to back out the segment trapezoids, if that’s even possible.
The gcode parser/interpreter does the vast majority of the calculation and inserts segments (called “blocks”) into the movement queue, and ISRs dequeue from the movement queue and manage the steppers. (This is why the queue not being depleted implies the 8-bit hamster wheel is keeping up with fancy gcode.)
When movements are inserted into the queue they can modify adjacent movements that are already in the queue, like forcing different acceleration if the start of the new movement is not compatible acceleration-wise with the end of the previous movement. This means it’s not enough to capture the segments as they are inserted into the queue. You have to capture them as they are coming out of the queue (or at least are not near the tail of the queue).
It’s not feasible to add serial diagnostic to the ISR that pulls from the head of the queue but perhaps there could be a mid-queue reporting feature that spews some segment information to the console…
Is it time to stop trying to bend Marlin to our will and just use GRBL? I am not concerned with printing anymore. large format printers are stupid cheap now so I don’t see any other need to use Marlin right?
Does GRBL_Esp32 support dual endstops or just dual motors?
Grbl also doesn’t work with octoprint.
I like grbl. But it won’t be perfect. It is a much smaller userbase. There are a lot fewer boards, and AFAIK, no 32 bit boards. It definitely wins in configuration simplicity (almost all eeprom, serial config). If you want something very different than the existing grbl, it will require more work. Marlin seems ok accepting all kinds of changes as PRs. The laser mode also works better than Marlin.
In terms of a turn key, reliable, stable controller, I think grbl on the esp board is probably hard to beat. In terms of things novices care about. For a kitchen sink, Marlin on a bleeding edge board will be better.
This is because, if the next move is to turn around, the previous move needs to stop. If it’s in the same direction, it doesn’t even have to slow down.
Gotcha. Makes sense. I guess I never really thought about where the numbers went as they were generated. The next command gets compared to make acceleration decisions. So still the same deal I guess I just used the wrong words. Looking to tap into the raw move commands. So maybe some sort of pin output log for speed and direction. Possibly even on the scope just to see if there is any difference.
I can’t seem to step through the equations but maybe I should give it another try. Since we are probably the only ones using the arcs, I have to assume the problem is there not in JD, or JD is not set to calc arcs correctly if at all?
