I just setup a raspberry pi with CNC.js and connected it directly to the Jackpot CNC controller as a GRBL controller. The first day of messing around with it went smoothly, though I never cut anything or ran any jobs (I’m working on some other upgrades, mostly just jogging the machine). I could move all 3 axes consistently and happily.
Then I did some rewiring, and rebooting things. And now the Z-axis moves at 1/8th the speed & distance. I can jog X and Y normally via CNC.js UI, and even if I switch to the FluidNC UI (which is running concurrently), it also runs XY fine but Z at 1/8th speed. I went into the FluidNC config and confirmed that z-motor microsteps is set to 8, so everything must think it’s 8, but the controller is driving each step as a 1/64th microstep.
And THEN, occasionally I restart everything and it’s all back to normal.
And one time it looked like jogging Y was fine but the two X-motors were off by… a factor of 2? They were clearly both moving, but it kept racking as one moved faster than the other.
I am not familiar enough with this setup to know how to debug this, either within Fluid or CNC.js. Should I even still have FluidNC/wifi/webui running? How do I check/modify/enforce microstep settings within Fluid or CNC.js? Any pointers are appreciated.
(Sorry there’s nothing very exciting in this picture, but the forum told me add one. You can see it thinks my Z-axis is at 431mm though!)
We need to see your $ss output from when it is misbehaving.
The most likely reason people run into this is because they attach the USB before the board has been powered, and then only the ESP32 initially powers up and FluidNC doesn’t initialize the TMC2209s correctly. There is a diode on the Jackpot to prevent backpowering the board from USB.
If you’re in this state, you can try sending $MI to FluidNC and it will try to reinitilize the drivers. That might correct things.
If you intend to leave the USB connected all the time from your control computer to the Jackpot, you might want to get or make a “data only” cable so that you can only power up the Jackpot from external power. That also prevents this issue for machines that stay always connected via USB.
Yes! This sounds like my problem. I’ve been annoyed that the board is powered via the USB from the Pi, didn’t realize that it could be source of such significant problems. I wasn’t sure if there was a way to disable that. I will look up how to splice a data-only USB cable.
Follow-up: This worked great! I cut off the insulation in the middle of the cable, snipped out a small section of the red wire to make sure it was full disconnected, and then wrapped up the section again with some electrical tape and heat shrink. The board now fully powers off when I turn off the power, and a whole bunch quirks with it have now been resolved. Thanks!
