Front right corner - Printer head collides with bump in front door

[sneggi]

If I have a cut close to front right corner, the printer head is colliding with the magnet-bump-out of the front door and causes a miss alignment in the x-axis for the rest of the cut.

After that, I turned off the forge and let it home again…
if I cut the same file again the head collides again…

Maybe that’s what causes also @ryanjpedersen some grief…:

Arg! alignment!

Alignment question here: I thought I have read all the alignment posts, and I thought I had it all figured out. To make this piece print, I had to make each part of the artwork a different operation, because the GF can’t handle it [map-08] I have a special operation, 4 dots, one in each corners, to carefully calibrate and overcome the GF’s all-over-the-board-alignment issues. Once it’s all aligned and where I want it, I start the print, but of course, I have to “ignore” several …

Apparently others had similar problems in that corner.

Maby shaving off some of that bump-out will fix the problem… or can you move my y-axis-zero up a notch?

[dwardio]

A short term workaround for the pattern you are working with would be to reduce the space between the individual pieces and move the whole thing “up” a bit. (I know – making a huge assumption here as I can’t see other end of the pieces. I could have figure & ground reversed.)

[scott.wiederhold]

I’ve run into this, as well. I just stay out of that area.

Discussion of June '17 update

Though, I just ran this on some painter’s tape I put on the crumbtray. The head hit the front door down in the right corner. [22] Caused the head to pivot off the magnet mount a bit, and redirected the laser forward. It was traveling from back to front at that point. When it traveled to the left, it snapped back into place. At least now I have a nice visual indicator on the crumbtray to tell me where the cuttable area is. Too bad it doesn’t match up to the GUI: [Capture]

[shawnxp2002]

I think there must have been an update and the program has an error in calculating the distance to move the head.

I just turned on mine and it hit the front and then kept trying to go, so i shut it off, unplugged it. then move it back to home position top left and turn on again. I did the same thing and Back on during calibrating it hit the front door. Third time had no issues.

[brandtmeister]

Yeah, I seem to have lost some space to the back, and gained space in the front where the head should have no business…

[mhumphrey]

My guess is that GF is making software changes, with new bugs, and these are slipping through whatever QA process they have and getting out into the wild before they’ve been adequately tested.

Just a guess. I’m seeing multiple threads with strange, never-before-seen behavior, and the only explanation I could come up with is new software bugs.

I guess on the positive side, it at least indicates some forward momentum on the software front.

[dan]

While the support team is working on the details of this case, in the past, head collisions have always been a hardware problem.

[mhumphrey]

Well @dan for GF v2, there is a stepper motor driver chip that can detect a limit situation (i.e. stalled / motor not moving) electronically, with no requirement for limit switches and also to detect unplanned obstructions in the work area. They are using these on the new Prusa MK3 3D printer.

The drivers are Trinamic TMC2130

TMC2130

[dan]

Thanks! We can already detect it on current hardware, although it’s not hooked up in software yet.

[jaz]

Thanks for reaching out. I’m looking into this.

[jaz]

Thanks for your patience. We’ve found that this unit has an issue that we cannot solve remotely. I recommend we initiate a warranty replacement. I’m very sorry for the bad news.