Hello everyone, thank you for your time! I have a pretty old (2002) goldensign laser cutter with a LaserCut5.3 controller. The other day it ran into a problem I hadn’t had before (I’ve been in charge of it for about a year): upon turning on the machine, the laser head would travel up to the top left corner (0,0) as usual but then would get stuck in that spot. It could travel along the ‘x’ axis, no problem, but would only minimally respond to ‘y’ axis commands to move north (before running into the edge of the worktable, where it would still try to move north despite being physically unable to do so). No luck at all trying to get it to move south past 0,0. When I try to download a file onto the machine, it promptly triggers the ‘soft stop’ error usually reserved for out of bounds files, despite correct laser head positioning and appropriate project size. I’ve been trying a few things but I haven’t been able to fully get it back to where it was, so I report here my findings just in case anyone has any input/ideas as to what might be happening/could be done:
If I stop the homing process right after turning on the machine, before it travels to (0,0), the machine will respond as it normally would have after homing. The laser head will travel all around the worktable along both axis and trying to run a file will not result in the ‘soft stop’ error. The only notable difference is that the movements will be a bit slower.
I have checked the worktable settings on LaserCut, and the size and direction appear to be correct.
I have turned off the machine, unplugged it, restarted both it and the program. Nothing has changed. Also ran through the actual machine settings and checked that the ‘set/change logic org’ settings, which occasionally have gone out of whack and given us some problems but all is good there.
I tried switching the axis plugs on the electrical board and that results in the ‘y’ control panel arrows working to move the laser head along the ‘x’ axis in both directions and the laser head still refusing to move along the ‘y’ axis, now controlled by the ‘x’ arrows. Returned plugs to their positions and it returned to the original problem.
This all happens within a college context - the machine is pretty much running all the time and operated by students with student worker aid, so I don’t know exactly what brought it on/if something was pressed. The student workers have told me there was no apparent problem before that, no banging of the laser head against the worktable margins, etc. Any thoughts?
It’s possible, albeit unlikely, the DIR wire from the controller to the stepper has become disconnected, so it’ll be worthwhile to verify both screw terminals are still tight and the wire has continuity in between.
Swapping the X and Y wiring should have ruled that out, but it’s faintly possible the terminal inside the stepper driver has failed: both the X and Y plugs will not make good contact.
Similarly, it’s possible the power supply wiring to that driver has failed or gone intermittent, but we’re now deep into the highly unlikely end of the pool. Make sure the green power LED is lit to rule out most of those problems.
Stepper drivers are relatively cheap and readily available, so get one that matches whatever is already in the machine, set the DIP switches accordingly, swap it in, and see if that improves the situation.
This sounds like a coordinate system issue. If it homes to the top-left, the position here should be maxY,0 not 0,0. 0,0 should be bottom-left. In grbl controllers, you set a workspace offset to make the controller home to maxY,0 and having the 0,0-position at the front-left. I don’t know your controller, but either you can set such an offset here as well, or you might need to change the origin within LB.
That’s the reason it can’t go down after homing, because it would run into negative space.
The overall limits would certainly apply to the original Y axis, but swapping the stepper driver controls should rule that out.
Having had time to think this over, perhaps the Y axis limit switch has failed.
The Ruida controller should have a Diagnostic display showing the state of the input signals; on my KT332N it’s hidden in Menu → Diagnoses. Manually triggering each switch should produce a corresponding change in its indicator.
