So I’m having an issue whereby the x axis will shift position while engraving, it will be quite happy going back and forth and then at some point the whole image will shift either left or right. Any thoughts as to what might be happening?
Running a GRBL_ESP32 based 6 Pack CNC controller, TMC2130 drivers, acceleration is all the way down to 100. Everything is nice and square, auto homing works great, not sure what it could be.
There are a variety of reasons steps are lost. The most common reason is a loose grub screw on a pulley. Other possibilities:
I doubt it is the feedrate or the grub screws since typically these lead to many smaller slips, not a giant one like I see here.
Thanks Robert, I think I have pinpointed this to be the result of a cheap-o PSU, it’s supposedly rated for 30A but after switching to a dedicated PSU for the laser module I haven’t had any further issues. So fingers crossed 
Gah - spoke too soon, just had another test fail in the same manner… Frustrating…
Have you set the current on the 2130s?
In Marlin, there is some feedback from the drivers. Things like an open loop flag for each coil. Is there a way to query for that in grbl_esp32?
I’ve played around some with the current, have them set to 1A at the moment, but same behavior regardless of what I’ve tried. Over 1A they no longer moved smoothly at low feed rates, not sure why though. Also not aware of a way to query the drivers directly. What would I be looking for if I could do that?
At higher amperage the drivers heat up and “stutter” when overheat protection causes them to pause. I’d consider lowering the current setting a bit.
Okay - fair enough, I switched them to coolstep which will only use as much current as necessary based on load, steppers running nice and cool as are the drivers. Still having issues though, and I switched to a good quality Meanwell PSU to rule that out.
A little more color on this - here are the extended LaserGRBL logs and something is definitely awry…
23495 05517365 tx G1X-14.54S0\n
23497 05517427 rx <Run|MPos:80.930,72.300,0.000|FS:390,0>\r
23498 05517476 rx ok\r
23499 05517477 tx G1X-3.26S150\n
23500 05517600 tx [3F]
23501 05517631 rx <Run|MPos:83.370,72.300,0.000|FS:1577,95>\r ----result of the -14.54 move, this is correct
23502 05517634 rx ok\r
23503 05517635 tx G1X-0.87S0\n
23504 05517801 tx [3F]
23505 05518001 tx [3F]
23506 05518047 rx ok\r
23507 05518048 tx G1X-0.03Y0.1S0\n
23508 05518117 rx ok\r
23509 05518118 tx G1X0.87S0\n
23510 05518120 rx ok\r
23511 05518120 tx G1X3.26S150\n
23512 05518123 rx ok\r
23513 05518124 tx G1X14.59S0\n
23514 05518127 rx ok\r
23515 05518128 tx G1X8.99S150\n
23516 05518131 rx ok\r
23517 05518133 tx G1X9.36S0\n
23518 05518133 rx ok\r
23519 05518135 tx G1X10.18S150\n
23520 05518137 rx ok\r
23521 05518137 tx G1X10.67S0\n
23522 05518141 rx ok\r
23523 05518141 tx G1X1.32S150\n
23524 05518141 tx G1X2.34S0\n — sum of x moves at this point from the 14 move is 57.42 so we should be at ~140
23525 05518144 rx ok\r
23574 05527767 rx <Idle|MPos:13.750,72.400,0.000|FS:0,0>\r ---- oh dear ???
Are you using relative or absolute g1 commands?
For the most common sources of skipping steps, the controller has no freakin’ clue that is skips. It looks to me like the position reporting is right, but the G1 commands are just a bit ahead. It reads too many commands (and says ‘ok’ to all of them), but it stores them in a buffer so it can do some speed planning ahead of time. While it is working through that buffer, it will report a position that is behind the most recent G1 command.
My guess is that this log is tricking you, because of the buffer, and something else is causing skipped steps. Either something is getting too hot, or not using enough current, something is binding, a coupler is loose (grub screws! 
), or you have an intermittent wiring issue.
No it was definitely incorrect - I’d posted this on the grbl_esp32 discord but this is running in synchronous mode and the machine pos was accurate showing where the machine was.
06267 71832331 tx G1X-11.08S0\n
06269 71832496 rx <Run|MPos:86.390,59.900,0.000|FS:1000,71>\r
06270 71832558 rx ok\r
06271 71832559 tx G1X-5.48S150\n
06272 71832633 rx ok\r
06273 71832635 tx G1X-26.77S0\n
06274 71832663 rx ok\r
06275 71832664 tx G1X-9.03S150\n
06277 71832700 rx <Run|MPos:83.370,59.900,0.000|FS:203,0|WCO:0.000,0.000,0.000>\r
06278 71832747 rx ok\r
06279 71832748 tx G1X-15.51S0\n
06281 71832899 rx <Run|MPos:85.500,60.000,0.000|FS:1000,71>\r <------ why are we now moving in a positive direction?
06282 71832976 rx ok\r
06283 71832977 tx G1X-3.75S150\n
06285 71833103 rx <Run|MPos:88.890,60.000,0.000|FS:1000,0|Ov:100,100,100>\r
06287 71833301 rx <Run|MPos:92.230,60.000,0.000|FS:1000,0>\r
06289 71833503 rx <Run|MPos:95.530,60.000,0.000|FS:1000,0>\r
06291 71833701 rx <Run|MPos:98.860,60.000,0.000|FS:1000,0>\r
06293 71833896 rx <Run|MPos:102.230,60.000,0.000|FS:1000,0>\r
06294 71833931 rx ok\r
06295 71833933 tx G1X-0.88S0\n
06297 71834095 rx <Run|MPos:105.530,60.000,0.000|FS:1000,71>\r
06298 71834270 tx [3F]
06299 71834292 rx <Run|MPos:108.830,60.000,0.000|FS:1000,71>\r
However I was able to finally resolve this…
I recompiled using platform.io, not sure Arduino IDE was picking the right versions
Turned off BT, Telnet and SD thinking having everything running was tapping the ESP32 out
Then I flipped my drivers around from XXY#ZY (port 4 is bad) to XXYY#Z keeping the Y’s together - (it’s a Bart Dring 6 pack cnc controller board)
I also added
#define BLOCK_BUFFER_SIZE 128 //250 or 16, default=15 or 16
#define SEGMENT_BUFFER_SIZE 16 //20 or 16, default=6
to my machine config
After those changes I was back in business - not sure which one did the trick and not sure I have the appetite to unwind the changes one by one to pinpoint, but I’m now confident enough to strap a router to this thing
Appreciate your feedback and suggestions.
