Zeroing Axes Glitch?

I noticed sometimes after having my axes zeroed in, when I load a new file into Firecontrol and hit “go to xy zero” it will zero itself in the middle of the table. I then have to rezero my axes back to the corner. It doesnt happen every time but its like a 50/50. Anyone having this issue?

So I noticed if I load a file first and then “go to xy zero” it works. But if I “go to xy zero” and then load file the zero becomes the center of the table

1 Like

@dj_elite thank you for bringing this to our attention. If we can reproduce this issue it should be no problem to fix for the next release.

We thank you for your valuable feedback! Feedback like this will help us to make FireControl very stable in the coming weeks.

2 Likes

The table+control doesn’t have a true XY zero. There are no limit switches to tell the software when it’s hit the “zero”. To this point, if you move the carriage to the absolute XY zero of the work envelope, hit “zero axes” in firecontrol, then jog the machine into zero (where the servos are stalling because it can’t move anymore), the firecontrol xy coordinates will move, but the zero will stay in the same place. The control software updates it’s torch position based on where it should be, in relation to the software defined XY zero, based on what it told the servo motors to do, not what they actually did. In my eyes, this is why the XY zero is not retained across programs. It seems to update with whatever you set as the origin in your CAM setup, meaning XY zero has to be reset for each program run. At least that’s what I’ve been seeing/doing.

The fact that the control software doesn’t truly know where the torch head is in relation to the table (due to lack of limit switches or a DRO) means you can set the XY zero say 10" below Y travel max with a 12" height program. When the program gets up to the top, it’ll just stall the Y axis but continue cutting. That bit me last week. I chalk it up to a user error (my error).

See example. The L is too short, and the C got all messed up (toolpath started at the bottom of the C and moved up):

Not true for me. If Ive already zeroed X and Y and then cut a program, when I load the next program I can just hit “go to xy zero” and it will go back to where I zeroed the first program (usually lower left corner). But if I hit “go to xy zero” and then load the next program the zero becomes the center of the table

Ok, interesting. Will try to reproduce today.

You’re saying that about 50% of the time you “hit ‘go to xy zero’ and then load the next program…” the zero is centered at the center of the table?

That was before I noticed if I load a file first and then “go to xy zero” it works

Just confirmed, I did not have this issue during my test tonight. Clicked “go to xy zero” and it went to the program zero. Loaded the next program, and the program loaded at the new program’s XY zero, not at the center of the table, but at current torch position.

Tried it twice, couldn’t reproduce.