My spindle dropped to the bottom of the Z axis

[supernat]

that is correct ger21. I originally thought it was just going down per cmd, but yeah it's just getting into an invalid position when it stalls. You mentioned the z acceleration, I just don't know enough about the architecture, but I assumed axiom would have configured the controller with the max accel and speeds, so either the hw is failing or they didn't configure the controller, or I'm just totally off in my assumptions. Which happens a lot. Hah.

[ger21]

That's why I mentioned it could be binding. It only takes a very, very slight misalignment of any of the Z axis components to create enough friction to see what you're seeing. The easiest way to check for binding is remove the motor, and turn the screw with your fingers. It should be very easy to lift the Z axis with just your fingers turning the screw.
Could be lots of things, though.

[Martin Reid]

Supernat...

Posting the video, good idea.

It definitely looks like a hardware problem to me, unless there is a 'command not recognised' in the post processed file. To eliminate the 'sofware' side of the equasion could you?

(1) Interrogate the post processed file around (93.661x, 174.268y) and check that the move z axis command is the same as all the other z axis commands.

(2) Try a different post processor to create the part and then air cut that.

Then armed with your video and explaining you have eliminated the 'software' its on to Axiom. I'm not sure what their after sales is like, but I seem to think you are about to find out!

This looks to be very frustrating and time consuming.

Best of luck
Martin

[supernat]

I did some more testing and found that even setting the Z axis max speed to 100mm/min was barely correcting the problem. Interestingly, the Z axis was still flying up and down while X/Y were dog slow, so that clued me in. I finally found that the Z axis retraction was using feed commands to move up/down instead of retraction commands and thus the high feed rate. See the screenshot with the blue lines going up/down. I only get this when the X/Y cut goes off the side of the material boundary, specifically when I added a boundary offset of 0.2" to the model. See the second screenshot where I don't add a boundary offset, and the green lines are retraction lines, and indeed use G Code G00 in the command file:

Using G1 movement commands (blue lines):
N941290G1X93.661Y174.260
N941300G1Z4.826
N941310G1X93.639Y174.966
N941320G1Z-27.938
N941330G1X93.503Y175.210

Vertical lines

Using retraction commands (green lines):
N93400G1X42.419Y132.070Z-17.580
N93410G1X42.423Y130.768Z-17.666
N93420G00Z5.080
N93430G00X35.475Y139.591
N93440G1Z-24.426F1200.0
N93450G1X35.233Y139.511Z-24.688F3000.0
N93460G1X34.991Y139.431Z-24.923

So I tried expanding the material work size larger than my actual material and recalculating, and viola (see next screenshot), the blue vertical feed lines disappear and no longer bind my Z axis. So I don't know if this is a Vectric bug after all, it appears to be. Does anyone else think this is a bug, or does this look like expected behavior? I think also that my controller should be limiting the Z axis movement speed based on the max speed limit I program too.

No retraction or feed lines in vertical at all, this is what I expect. Unfortunately, I had to increase the material size larger than my real material, which means I will have to offset the origin when cutting.

[supernat]

Supernat...

Posting the video, good idea.

It definitely looks like a hardware problem to me, unless there is a 'command not recognised' in the post processed file. To eliminate the 'sofware' side of the equasion could you?

(1) Interrogate the post processed file around (93.661x, 174.268y) and check that the move z axis command is the same as all the other z axis commands.

(2) Try a different post processor to create the part and then air cut that.

Then armed with your video and explaining you have eliminated the 'software' its on to Axiom. I'm not sure what their after sales is like, but I seem to think you are about to find out!

This looks to be very frustrating and time consuming.

Best of luck
Martin

Thanks Martin, frustrating indeed, but I think I finally got down to the real issue at least. I always enjoy a good mystery though. Axiom was good with customer service when I contacted them, though they are a bit slow to respond. I did have a screw that fell out upon delivery, and they helped very well. I'm still waiting to hear back from them currently on this issue, but at least I have a work around now. I am going to submit this as a bug to Vectric and see what they think. They also responded well the last time I had an issue with the depth of cut not being equal on both sides of a molding toolpath even though the molding was at Z=0 on both sides.

[ger21]

Regardless of whether or not the retracts are G1 moves, it should not be stalling. This is a problem with your machine control or machine setup. Generally, rapid moves would be the fastest moves your machine could make. Any feedrate moves specified as faster than the rapid rate should not move faster than the rapid rate.
Bottom line, is your machine should not be stalling while running code. If it does, it's not the fault of the code.


Whether or not the moves should be G0 or G1 is a separate issue.

[ryadia]

I may be a bit late into this thread but I had this issue many times prior to having my Controller rebuilt. Whenever I moved the gantry out of the way to get better access to either load another piece or needed to examine the cut before proceeding, Mach3 would not return to zero and start again. It just plowed straight into the waste board ruining a sheet of perspex in the process. Does any of this seem familiar to you?

If so, you will have to involve yourself in 'tuning the motors' (part of Mach3 configuration) or get someone to help you. Either the acceleration of the spindle or Z axis is too fast and it drops out ...or the axis speed is too slow and the motors trip over themselves where they should be and lose instruction. This is supposed to be addressed in Mach4. Have you considered contacting your supplier?

Ryadia