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.
Which side is the bottom? The door side?
Yeah close to the door
After a power cycle, and calibration, it is still doing the same thing.
You can see the head hit the door when it reaches the end of it’s Y move, and then it appears to tip back to normal after it begins the X move.
Here are the witness marks on the head:
Here is the result of the bump on the cut:
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.
Collisions are definitely bugs and we would love to hear about them. It won’t damage your machine but could ruin your print.
Well it has caused cosmetic damage, see the marks on the head. Why don’t the accelerometers in the head detect it?
And if it rotates the head isn’t there the possibility the beam will miss the entry window and etch the coating off the side of the head?
It’s probably in the hopper.
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.
Except that Dan showed us all a video showing it working. Note the tense: https://www.youtube.com/watch?&v=nvYu7Vbx2oM
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.
Has anybody tried the cup of coffee test?
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.
I doubt the beam density is sufficiently high at that point. IIRC the beam is about 5mm prior to focusing.
