Odd issues that suddenly started with the motors

Had a really wierd problem start last night. All of my motors are moving…but at different speeds. X1 and X2 move at different speeds. Same with the Y motors. I know they are moving because one hits it’s end stop before the other but the other keeps moving. But then why I move away from the end stop you can see the gantry start to skew. No idea why. Microsteps are set the same for both motors on each axis. Nothing else has changed…except trying to connect to CNCjs on my computer via USB. Not sure how that would affect it, though.

Any thoughts? yaml file is posted.

config.zip (1.4 KB)

-Ryan J.
Definitely not “The” Ryan

Oddly enough the problem was the connection to CNCjs. I couldn’t get that connection to work and I think I forgot to terminate the connection. Took the cable out of my computer and all is working again through the webUI.

An observation about that- We’ve seen where host software can impact the Jackpot depending on what it does with the hardware handshaking signals (e.g. Lightburn needs to have a setting for DTS or it messes up the jackpot). We’ve also seen users with a different problem where they need to have a pullup installed or the ESP32 doesn’t boot reliably.

In either of those cases, if FluidNC boots abnormally and doesn’t properly read the config.yaml it can end up misconfiguring the motors and get weirdly different behavior like two motors on the same axis moving at different rates.

Although you mark your removing the USB cable as a solution, it’s worth considering that you may still want to track whether you have issues when connecting your host software.
The jackpot could be rebooting in unexpected ways/times, and that might pose issues for you in future operations.

CNC.js said they actually had to do some sort of update recently in the FluidNC discord. That could have played a part.

I agree with MakerJim though, if this happens more might want to add a pull-up resistor to the esp, seems to help some of the boot issues.

Well, i just drilled 367 holes using the webgui with no issue.

1 Like

When FluidNC boots correctly and nothing perturbs that, the WebUI seems to run really well.

Having the WebUI available is going to really work out well for a lot of users since this takes a lot of host side issues out of the equation.


I had one issue running a pocket where everything just stopped moving for about 20 seconds. My guess would be that the ESP memory was full. It eventually started again and finished with no loss of position. I have never had that happen when using a PC as a host so I was looking into CNCjs. Can’t get a handshake, though, so I’ll stick with the webgui for now.

Using 3.7.8 and the current configs?

I think that happened on the very first release for some people. That should all be fixed now. You can cause it if you refresh the UI too often though.

I’ll have to check tomorrow to see what version I’m using. Didn’t refresh the gui at all so that shouldn’t have been the problem.