Upon startup, the XY stage will step through a series of positions before going to its home position in the upper-left corner of the bed. If I power up with material on the bed (specifically a half-used sheet of Proofgrade acrylic) I’ve observed the stage crashing into the ends of its travel (back and/or left/right sides). It will continue crashing about until I power off the system. If I clear the bed of the apparently jinxed sheet of Proofgrade acrylic prior to power-up, the system initializes without incident. I have left other items, such as sheets of paper/cardboard and little magnets on the bed prior to this with no startup issues. Weird…
It appears I can dodge the issue by manually moving the gantry away from the home position, (e.g. front/center with the laser head under the camera) before powering up. When starting up with the gantry front/center, the startup routines seem to correctly detect travel limits - no crashing into the back or sides. So FYI for anyone else who’s experienced this startup fail.
So I’m just speculating, but I can think of a few causes:
Something is interfering with the operation of the endstop detectors, like debris from cutting flyaway materials like paper. If someone could tell me where the endstop detectors are located, I’d be happy to check. However, powering up with the gantry moved out of the home position seems to contraindicate this as a root cause.
Or the endstop only detects when a threshold has been crossed, such that it might be possible to position the gantry on the wrong side of the threshold detection, rendering the startup routines confused. While this could explain why starting with the gantry out of the home position dodges the issue, I’d like to think this would have been caught during the extensive testing, but ya never know.
There is no discrete endstop detection; it’s all done with the camera and software. While that might seem clever, it also raises the potential of the startup routines being fooled by whatever’s on the bed when the system is powered up. This is my favorite theory, as I can’t locate any discrete endstop detectors, and clearing the bed before power-up seems to dodge the issue.
I confess I never read the manual - is there one? Perhaps it’s been documented that the system should be powered up with the bed cleared, in which case, my bad.
It’s 3. Dan has commented before that there are no limit switches. That GlowForge logo on the back of the print head isn’t just decorative; you’ll notice during calibration that it gets centered under the lid camera.
jwalton, by messing with the starting location of the gantry prior to power-up, I’ve observed the startup process not park the laser head under the camera and still get to a “Ready” state. Now I’m wondering if that was a legit calibration if it doesn’t park the logo right under the camera…
It doesn’t park the head under the camera. Once it centers the head it moves it back to the left side, does a couple of small Y gantry moves, then parks the head in the left rear.
johnse, sorry - by “park” I didn’t mean that to be the home position at the end of the calibration process. I meant to say that I’ve observed calibration runs where the Glowforge logo never positions under the camera prior to coming to a “Ready” state in the upper-left corner.
The head is always parked in the back left corner after a cut or after a successful calibration. Usually calibration is only done once at power up. Occasionally a separate calibration is done with a S/W update or if it loses calibration for unknown reasons.
A normal calibration takes about 90 seconds. The head will move from the parked position to somewhere near the lid camera. It will move through one or more steps to be precisely under the camera. Then it will move to the left side. Move about an inch toward the front. Move a couple inches toward the back and in a few seconds move to the parked position in the back left.
If the lid camera loses track of the head position or can’t clearly see it in the parked position due to overhead lighting or other conditions the head may move in a different pattern. According to support the bouncing along the left side will not harm the GF. It does make a hell of a racket and often tilts the head off of the magnetic base. Moving the head so that the camera can clearly see the head on power up will solve the calibration issues. Though usually it’s not needed.
I can force the head banging on my unit during calibration with unusual lighting or certain material patterns on the bed but 98% of the time the calibration process works smoothly.
Yes unfortunately only the black side of the head is visible to the camera in a dark corner of the machine so it gets fooled easily. Lots of ways they could fix it, such as assuming it is parked, moving a little forward and right and looking for what moves in the scene to get a positive fix and then simply move to the centre. In most cases (when the head has not been moved) it would be spot on with the logo and one more shot and move should be it. So simply three camera shots and three motion plans, done.
No idea why they haven’t fixed anything to do with the camera for many many months. Perhaps they are waiting until we have all accepted our machines before revealing how well the alignment will work.
They appear to have changed something in the last week or so. The first move used to be a Y move that caused the aforementioned bouncing of the head on the left side (not head banging as in trying to move left, more like hitting something).
I was going to take a video of it…and the head moved diagonally instead.
I’ve often thought the same but now I of the belief that the different movements have lighting, reflections, user moves of the head to extremes, or cutouts that fool the camera as causes.
I can repeat these conditions with identical results…
So I’m thinking my best bet is to duplicate the power-up conditions under which the software was developed. Anything else could expose a corner-case the software hasn’t accounted for.
I’m betting the code was written with the bed empty, so I’ll clear everything out before powering up. While head-crashing isn’t an insta-kill for the gantry system, it can accumulate damage over time that could alter the performance in subtly undesirable ways.
When utilizing power equipment, especially those that vaporize materials and could potentially cause severe ocular damage if not properly used, it is always wise to read the manual.
Check your emails from GF. Go to the manual. Open the manual. Read the manual.
The community here is great and their advice and insights next to none – but they do not replace the information in the manual.
rand, so marmark3261 did point out where to find the online manual. Turns out I actually had read that manual - I guess it didn’t register in my head as the manual. In retrospect I should have stated something more along the lines of a “User Guide”.
Once I observed the head-crashing during startup was behavioral rather than symptomatic (e.g. I could repeatably influence it) I posted here to see what the other Glowpeeps thought about it, along with the hope that it was already well-documented. I was really rooting for the manual to cover things like what I observed, given the self-destructive nature of the malfunction. Alas, it turns out it does not appear to be covered in the online manual, so having read the manual first wouldn’t have obviated my posting.
Perhaps these forums are a form of a “living” user guide. Doesn’t replace the contents of the manual, but does augment it. My thanks to all who posted their helpful remarks. Here’s hoping GF improves the startup code so they never have to document this misbehavior in future additions to their manual.
Well said…the forum users here are an incredible resource of knowledge and assistance and support – I would never want to denigrate either the contributions or resources here.
I have found that after one of the more recent updates, my head rarely (I won’t say never) has that problem now…
Thanks for the answers everyone! I’m going to close this thread - if the problem reoccurs, go ahead and post a new topic. Thanks for letting us know about this!
