Yesterday I confirmed this is not my gcode, it’s been a long standing issue for me. Often, at the start of a job, after I’ve set up and begun the gcode, the first move is slowly off in a random direction in space, usually in the positive direction on all axes. It’ll show on the screen that it’s trying to go to coordinates my machine can’t even reach and certainly aren’t in the gcode. When this happens, the only thing I can do is reset the machine and redo my setup.
Yesterday it happened again and I tried rerunning without redoing the gcode file. The second attempt ran perfectly, so I know it’s not in the gcode. I’m worried it’s happening because I tend to do my setup in touchscreen mode and then flip to Marlin mode before beginning, in order to dodge the job lockup problem the SKR has with the TFT.
This isn’t it. I always home the machine and set up my jobs. Further, during these erroneous moves, the display shows the target coordinates, and they’re well in excess of the maximum ranges of the gcode or the machine.
I don’t use Marlin or a touch screen, so I can only throw questions in from the sidelines, but I wonder if the two different modes are using two different coordinate systems. Don’t know how you’d try to verify that hypothesis.
I’ve seen issues on the forum with electronic noise on the cables between the display and the control board. Are you running the SD card from the display?
I am, yeah, though my enclosure allows me access to the board SD slot. When I try to use it though, nothing happens. Do I need to recompile the firmware to enable it?
I don’t have an SDR Pro, so I’m only reflecting things that have come across the forum. According to this post from Nov, '20, the onboard SD slot is not supported by Marlin. Things may have changed since then.
If you think that noise might the be issue, I’d reroute the display cables, and/or shield them.
Are the coordinates random, or are they the same? If they’re the same, it’s less likely to be noise. You can enable line numbers and checksums for the Gcode, most slicers support it. That will prevent random stuff from interfering. It will reject garbled Gcode with invalid checksums.
Noise is a possible culprit if the cables are too long, but the normal cable for that is reasonable, so long as you still have the ferrite bead on your router power cable. Shielding won’t hurt though. Ground the shield at one end only to prevent ground looping.
The onboard slot is still unsupported by Marlin, so it gets used to flash firmware only.