I turned on my Glowforge, and was immediately distracted. I left it alone overnight (not burning anything, just on), and returned to it the next morning.
Well, it apparently didn’t complete the homing sequence. The carriage was in the center Y position, and it was repeatedly banging the head against the left side.
I know the “official” position is that this will not cause any damage to the Glowforge, but I respectfully disagree.
(Preface: At least on my machine) There is not a physical stop for the head to hit against on the left side. Instead, the head circuit board hits up against ribbon cable and pushes it into the cable guide and ultimately against the X stepper motor.
While one or two (or twenty) times may not result in any failure, repeated bumping against that ribbon cable is likely to cause a fatigue crack in that cable.
You can see the creases that are already present on mine:
Good edge case! Looks like something they should address. I hate to say anything “should be easy,” because “easy” is a four-letter word… but… hopefully it is easy to add a watchdog timer to the homing sequence so it doesn’t headbang overnight.
Cloud uses machine vision to attempt to locate the head.
Cloud generates PULS file that contains stepper waveforms to move the head.
Glowforge downloads, and blindly runs PULS file.
Go back to Step 1.
The problem is that it gets stuck in a loop where the cloud thinks the head is not far enough to the left.
One would think that they can keep track of how many steps to the left they have sent the device and at least know that they have sent enough for it to have traveled the entire possible distance. There is a physical limit to distance the X-axis can travel, after all.
Once they have sent enough steps to have moved the head a significant distance, if the CV algorithm still can’t pick out the head, they should halt the homing sequence and raise an error.
Continuing to beat the head against a wall ad infinitum is probably not the best option.
The circuit board hitting against that ribbon cable is what everyone is reporting as bumping along the left rail. The head is actually a long distance from the rail or anything on the left side. Just looks that way.
Not without a fair amount of disassembly, I’m afraid.
The cable snakes down through a flexible cable tray and connects to the interconnect PCB on the left side. There is quite a bit of other stuff running through that cable tray (coolant tubing, high-voltage wire, x-stepper cables, etc) that would make it unlikely that you would be able to pull it through without splitting it open.
I think it would be hard to do without removing the left top cover.
My CNCs have this feature, which I have had to take advantage of a number of times when accidentally running a gantry to a limit–and that’s in cases where I have limit switches (which I have had fail).
who made them (3M’s thin adhesive tape is usually pretty good),
the surface (semi porous works best, a smooth lacquered wood coat fails by allowing it to slide around, fibrous is a complete waste)
the coefficient of friction related to the material (adheres to ABS or nylon plastic best, PET or polyester is okay to poor, but PTFE or other slippery plastics not so much)
relative humidity (very low/high causes the glue to dry/wet and release)
I’m not sure where you would place those in this situation.
I would think the best place for a bumper-stop would be somewhere that the actual carriage would make contact with it, and not the head assembly that is riding on it.
Driving the magnetically attached, and presumably fragile, head assembly into anything - even if it is a rubber stop - seems unwise.
What might be cool (this is kind of out there, but humor me) is if you hooked up a bumper that contained inside of it some kind of pressure sensor, or perhaps a microswitch with an arm on it, and you could wire that to an input on the processor in such a way that it stopped moving the head if it made contact with this switch at the limit of travel. Nah, that’s silly. Maybe instead the unused internal speaker could be repurposed as a microphone and use some kind of cloud-based echolocation service to detect the distance to the printhead. Machine learning, yadda yadda, problem solved.
I don’t know, it seems like these science fiction inspired pressure sensors you’re describing would need wires though, and those are prohibitively expensive.
And think of the hassles the customers would have to endure if these sensors failed 0.01% of the time.