Z-Zero shifting mid-process

[sharkcutup]

by Dan O

Am I seeing your tool parameters correctly? The Amana settings are in "Inches per second" and the other is "Inches per minute" If those are your settings, that might be an issue.

Wow! That is a good catch TOO!!!

So many settings to check and keep an eye on! I wonder if it is possible to incorporate a locking feature for some or all settings once satisfactory projects have been produced with a particular .crv file. Maybe something Vectric programmers could consider, HUH?

Sharkcutup

[MillAlien]

Hi everybody- Yes, yes and yes.

Laguna and y’all targeted my plunge setting as way too aggressive. So I’ll fix that and note that internet learning for dummies is tricky - I’d simply set the plunge as 1/2 the feed as per what seems to be a general rule of thumb. Now I know better. Laguna’s tech recommended a plunge of <30 IPM in response to my latest observation.

The IPM v IPS change came when I reset the parakeets (parameters but that’s an hysterical auto spell so I’m keeping it) using the chip load formula. Amana’s default parameter is IPS in their library.

So back to the drawing board, but at least I seem to have a pretty good bead on what’s going on.

[TReischl]

.... I’d simply set the plunge as 1/2 the feed as per what seems to be a general rule of thumb. Now I know better. Laguna’s tech recommended a plunge of <30 IPM in response to my latest observation.

.

Not sure where you read or heard that, but that is not a "general rule of thumb".

[MillAlien]

[/quote].

Not sure where you read or heard that, but that is not a "general rule of thumb".
[/quote]

Youtube.

Anyway, reducing the plunge rate made no difference - same failure case - and this appears to be a problem only on multi-pass roughing paths. It's as if the pass step-down is in the wrong place in the G-code.

[adze_cnc]

It's as if the pass step-down is in the wrong place in the G-code.

Looking at the g-code should determine that.

[TReischl]

.

Not sure where you read or heard that, but that is not a "general rule of thumb".
[/quote]

Youtube.

Anyway, reducing the plunge rate made no difference - same failure case - and this appears to be a problem only on multi-pass roughing paths. It's as if the pass step-down is in the wrong place in the G-code.
[/quote]

YouTube has a lot of great information, it also has a lot of bogus info posted by wannabe "experts". I use it a lot to learn things. Right now I am setting up a stepper motor to do power feed on a small milling machine using an Arduino. This is the first time I have done anything like this. Watched a ton of videos, some of them are spot on, others, not so much. Just because someone posts a video on YouTube does not make the information correct.

About your issue. Adze is right, a look into the gcode will tell you definitively what is going on. It will end your thinking the software might be doing it. Might be time to learn how to read it. If you dig back through my 14+ years of posts you will never see a question from me like the one you are trying to resolve. That is because I can read g code. So if I am stumped by something the machine does I take a quick look. That said, in 14 years I have never found any issue with the g code. Plenty of issues with me or the machine though, LOL. There is nothing unique about your machine or what you are doing, if there was a problem like that the forum would be flooded with people complaining about it. Gotta remember, there are thousands of users writing untold numbers programs just like yours everyday out here.

[MillAlien]

It's as if the pass step-down is in the wrong place in the G-code.

Looking at the g-code should determine that.

What is it that I'm looking for?

[adze_cnc]

You are looking for cases where the Z cut depth is exceeding the expected maximum.

An example: for this roughing pass (with a Z-zero set to material surface):

If I look at the "Material Setup" I see that the "Model Thickness" is 0.25 inches:

So I don't expect the roughing pass to exceed that. But, since my roughing has a "Machining Allowance" of 0.01":

The maximum Z depth should not be more than 0.24".

I saved just the roughing toolpath to an NC (equivalent to your MMG) text file. I then used a text editor and searched for "Z-0.24". Nothing was there. "Z-0.23" nope. "Z-0.22" gave me:

Code: Select all

N31395  Y1.8619 Z-0.0816
N31400  Y1.7607 Z-0.1204
N31405  Y1.7218 Z-0.1409
N31410  Y1.6518 Z-0.2081

N31415  Y1.5350 Z-0.2202

N31420  Y1.4416 Z-0.2049
N31425  Y1.3405 Z-0.2033
N31430  Y1.2860 Z-0.1858
N31435  Y1.2393 Z-0.1704

If I was experiencing your problem I'd search for progressively deeper Z values Z-0.25, Z-0.26, Z-0.27, Z-0.28, Z-0.29, etc. until I either found one or didn't find one.

[MillAlien]

You are looking for cases where the Z cut depth is exceeding the expected maximum.

...

That's extremely helpful - I've been very interested in understanding g-code and since VCarve is my window, your mini-tutorial is really useful information. I'll be digging in.

Also, I ran the .mmg file in a toolpath simulator and I do NOT see the step-downs in the simulation, so my guess is that when I review the code lines I likely will not find the failure case (as predicted by you and others.)

So what I know so far is that:

1. The only toolpaths with errors are multi-pass roughing passes - I've run single pass roughing and finish (e.g., single-pass) 2.5D tool paths with no problems, yet multi-pass roughing passes always have errant step downs.

2. The errant step downs always occur in exactly the same coordinate position relative to the workpiece's XYZ-0 origin for every toolpath. I ran one toolpath four times - the step downs are in the same places on each; I ran another toolpath from a different model twice and again, the errant step downs are the same on both of those; I ran a third toolpath .. ditto.

3. Changes in tool parameters change path times, cut quality & etc., but never resolve the errant step downs unless the pass depth is set such that there is no second (or third) pass.

4. The VCarve post-processed gcode appears to be error free on the CAMnotics simulation, which rules out a post-processor issue in VCarve.

So what's left? Doesn't this point to a controller system failure? What's done about that sort of thing? Firmware re-install? Are there boards or some other quasi-consumables that could have failed?

[TReischl]

What does Laguna say? That is a fairly pricey machine and certainly no toy.

What happens if you create a different set of geometry and use the same cutting techniques?

[MillAlien]

What does Laguna say? That is a fairly pricey machine and certainly no toy.

What happens if you create a different set of geometry and use the same cutting techniques?

Laguna has been moving along in a very supportive way. They're looking at the .crv failure files now and I think will be loaning me a temporary RichAuto A11 controller.

I've been using two different models as the test cases and both have the same errant plunge problem on multi-pass roughing tool paths. (One of the models is Design & Make clipart and the other an STL I bought off Etsy for $3.00.)

They're also not models I'd previously produced, so today's experiment will be to run a model that I've carved successfully before.

[MillAlien]

Just to close the book on this for posterity ...

The issue was resolved with a firmware update - both test cases ran without failure following the update of the firmware package from Laguna using the same controller pendant that I'd been using.