It could have just been out of alignment. Ill power cycle it and run it again.
Not to add to the pile of horse carcasses, but limit switches are very effective at preventing over travel in situations where the unit is no longer calibrated.
Super sensitive accelerometers in the laser head could, in theory, accomplish similar things.
When the head parks at the back it is completely out of the camera view. Is there room for it to travel to the RHS while being at the Y park position? If so they seem to be wasting a large amount of possible cut area. The camera seems to be a bit too far forward because it can see the back of the front door.
Not being ably to cut the full 12" width of the material is a massive disadvantage.
I lost 2 huge jobs to this problem before I found out what was causing it. I now have a stack of a hundred incorrectly engraved tokens. I will no longer run jobs to the bottom of the bed, I was hoping this was just a PRU issue. Im sad to see that it is not.
As a side note, of little importance: I did about 10 power cycles yesterday testing repeat-ability of the homing process (around ±.004" on my machine, not bad…). And the sequence was: Y-move to center, 1 or more (this varied from 1 to 3) X-Moves to center, quick adjustment jump to center, X- to left, Y to rear.
Just now, it was X-Y move to near center (single move), quick adjustment jump to center, and the normal return to rear left. So, it appears there may have been a cloud software homing sequence change between then and now.
Shhh… The likely outcome of that will be less usable space.
Like @takitus, I’m just avoiding that very small area. It’s about 1/4" sq. in. out of 214 sq. in. of usable space. Plus, they have clearly stated in numerous other threads that the usable area is a work in progress.
I’m not being sarcastic, I really mean that they have probably thought about it but not yet made it a priority to implement. Clearly they are behind on the software on many fronts.
There’s working well enough for a video preview, and there is working well enough to ship. If the feature was fully baked I am sure they would release it.
If it is only in the hopper the video was a lie then. It didn’t say it will do it in the future. It said it does it and gave a demonstration. Who would take that to mean it was an idea in the hopper and not actually be in production machines 10 months later?
And since it can potentially knock its own head off and let the beam go past it seems quite important.
Preemptive disclaimer to reduce likelihood of shout-downing: I’m sure they’ve already thoroughly examined all of this… I’m just pontificating:
I see some basic issues with using an accelerometer in the head to detect collisions.
I think the sensitivity would be very limited in this implementation. The head is constantly moving during a run, so you would get constant delta on the sensor.
One option would be to compare expected output with real output. A bit advanced in this circumstance, I think, as they are only sending step data so it would have to be calculated locally in real time. I just don’t see that as feasible here, especially since the communication between the head devices and the main board seems to be I2C. You could miss critical data points in between messages.
Another option would be to set an arbitrary threshold that is monitored by a microcontroller locally on the head (there is already a KL17 there now), and send a fault message up the I2C to the main controller board when the head hits something.
If you are going to detect both X and Y collisions it must be in the head. Since they are generally 3 axis one there would also detect gantry collisions.
The motion will have a software defined acceleration (which seems quite low) so you could just set a limit to detect hard knocks. Perhaps some filtering to remove stepper ringing.
Yes I would expect it to be monitored locally and passed upstream.
I haven’t tried it with a cup of coffee. I failed to pull the honeycomb for one of my jigs, and the laser did not stop on collision with it. On the other hand, the jig is cardboard and weighs about 2 ounces. It slides easily on the honeycomb. It did not strike anything with any force or resistance to it.