As you may be aware, we’re still having some problems with the lasers getting damaged by running the head into the bed or the material. Based on reports from users it usually goes something like this:
User accidentally moves the bed up when they mean to move it down, or they just go too far upwards using the manual keys on the controller or the software.
The probe hits the material, but the controller only registers probe hits during the auto-focus routine, so the bed keeps going up.
Horrible grinding noises ensue.
Emergency stop is pressed.
User takes a few deep breaths, then restarts the machine to try fix the issue.
Machine commences automatic X/Y homing, dragging the head across the bed or the material and causing further damage.
Emergency stop gets smashed again.
User admits defeat and asks for help.
So it largely boils down to user error, but the machine could do a lot more to help prevent damage. Since we can’t make changes to the firmware on the controller we’ll have to look at making mechanical or electrical changes to make up for its shortcomings. Here’s what I think we could do to prevent most of our current issues:
Stop the X and Y axes from moving while the probe is triggered. This would:
Prevent the head from being dragged along the bed and torn apart.
Stop the bed from raising further when the probe is triggered. This would:
Prevent the head from getting smashed into the bed or material.
Prevent the bed from getting out of level as it smashes into the head.
The first should be pretty simple. The motor drivers have an enable input that is currently not in use, and could be wired up to the focus switch to disable the X and Y axes when the probe is tripped. This would not prevent the head from smashing into things, but would prevent it from getting dragged when the machine is restarted. All that would be required is running an extra wire to probe switches and adding a couple of connections to the motor drivers.
The second will be a little trickier, but still not too hard. If we completely disable the Z axis when the probe is tripped it would always get stuck during the auto-focus routine. We would need to add an additional logic circuit that would disable the stepper driver only if the probe is tripped and the direction input is upwards. This would stop the bed from raising further when the probe is tripped, but still allow it to lower.
Anyone have any thoughts on this? See any potential issues? Want to help implement the changes?
Okay, so we take the spinning mirror module we got out of the old laser printer.
Mount it at the edge of the bed so that the laser beam sweeps the entire area just above the bed. Add a sensor to the head that triggers when the beam sweeps past it and disables any upward z-axis movement.
That trigger also activates an ESP32, which logs into the network, finds the info for the current user, then deactivates their laser access authorization as well as their building key, then posts their information and photo on the website with a large “LASER ABUSER” caption.
It will also send an email to Security to have the offender escorted from the building, and notify our attorneys that we’ll be commencing collection action for the cost of a new laser head and bed. The ESP32 can then contact the color laser in the Print Shop to print a “Wanted” poster with the offender’s information on it.
Don’t worry, I have no plans to print posters or implement laser defense systems. David can handle that portion of the project. I’ll stick to the practical stuff
Here’s what the “Probe Safety System” circuit will probably look like. The only downside that I can think of is that if this gets triggered and prevents a head drag the software will not have an accurate x/y position anymore. This could cause a crash on the left or bottom of the machine, but this is better than smashing the head. Implementing minimum limit switches should fix this issue.
My entire post was tongue-in-cheek. Christian is far more qualified to come up with a solution than I am, and more likely to get it completed. There are no plans on “outing”, sanctioning, or suspending anyone who accidentally crashes the laser head.
wouldnt it be better to have the S1 and S2 in a OR configuration instead of AND? I could see a situation where one gets triggered but the other doesnt for some reason and causes a head crash
They are wired in series using the normally closed (N.C.) terminal, so that is an OR configuration. If either switch is hit (or a wire breaks) the ground connection will be lost and the limit input will be pulled to +5V.
Okay, after a bit of testing I’ve tweaked the circuit layout a bit. I also enabled the firmware setting so that it will actually stop the head when it hits the X or Y limit switches (I thought that was already enabled). Unfortunately we can’t set this for the Z axis because it breaks the autofocus routine. I also added a switch to the layout for changing between cartesian and rotary mode.
I’m going to solder up a circuit to test on Mario. I would also like to replace the Y- limit switch that broke a while back. @ssaner did you say you ordered extra limit switches when you replaced the Y+ switch? We should also looking at adding minimum limit switches for Luigi. It uses inductive switches; we have one extra from the original autofocus, so we’ll either have to order another one or use mechanical switches.
A form of the circuit posted above was installed on Mario sometime around August 2019, and as far as I know it did its job without causing too much hassle for laser users. In addition to the planned protection I also set it up to disable the Z-axis when the limit switch at the bottom is triggered so that the bed can’t be crashed when lowering.
I did find a minor issue, though: when running the focus routine, the laser position can shift slightly (<1mm) due to the disabling/enabling of the motor drivers. Because of this, I’m going to try a different configuration that uses AND gates to block the step signals to the driver rather than using the built-in enable inputs. This way the motor won’t ever be unpowered, and position should be properly maintained while focusing.
Here’s the new circuit with corresponding logic formulae. Feel free to check my work and tell me if I messed up.
LZ- = Negative Z Limit input
LZ+ = Positive Z Limit input
DZ = Z Direction input
SZ = Z Step input
SX = X Step input
SY = Y Step input
SX’ = X Step output
SY’ = Y Step output
SZ’ = Z Step output
Thanks. I think I’m the first person to do that on the green machine. The auto-home at start up was the real killer. Are there any inputs that the software can monitor to stop x-y that once cleared will allow the software to resume or be reset?
Not on the stock controller. The add-on that I built prevents X/Y movement when the probe or minimum Z limit are tripped, so that should prevent most head dragging on restart issues. I do still need to build a new probe and protection circuit for Luigi. We could add a hardware switch to disable the horizontal axes, but the same can also be achieved by unplugging the control signals to the drivers before turning the machine back on. The way I see it, the main issue with manual override is that people won’t think about it before the dragging begins.
Oh, you can cancel the homing sequence by hitting the ‘esc’ button during startup, but it usually still moves a bit before it cancels.
