Strange depth issue

[knight_toolworks]

this seems to be random but it is there. I had out a sheet of 3/4" ply and the final pass was .77 when I removed the parts I found some where only cut out part way. the strange thing was the center cut was the right depth. just the outside cut was off on some pieces. like very other piece was not cut at full depth.
today I was cutting some more 3/4" ply in two passes/two bits since I did not have a 1/4" compression bit.
anyway on the second pass the first piece was cut at .77 like it was supposed to be. but the second piece was at .65 the running script showed .77 but the readout was showing .65 any idea's? this is in the newest software on my prt alpha.

[gene]

What max depth per cut do you have the bit set on in the library ? Could this be it?

[knight_toolworks]

the max depth was .77 as it was the cleanup pass. most of the cuts were right but a few were .64
thats the3 strange thing that some parts were cut right some wrong all where on the same toolpath and duplicate parts.

[jhicks]

Loose Bit? Not likely but it has happened.
Its not uncommon for sheet stock to be bowed or cupped so if its not vacuumed down that might be another possible cause.
Then of course its the material thickness variations one can see even in a full bunk of material.
We see thickness vary as much as .730 to.780 for 3/4 stock. Add some cupping and things get unusual especially if one zeroes Z on the high spot.
Did you zero Z in the same place on each sheet?
Once we have a Z depth that hits the table/spoil board, we just keep cutting with the knowlege that each sheet may be different thickness but the bit is coming down to the right spot. if the dadoes are a bit deper on one sheet than another we really dont care since they are blind dado's anyway and we always run the dado depth at .265 and use a male pin cut at.250 so they always fit.
Good luck finding the cause.
Could also be dust under a section of the panel even with a vac hold down.

Were the shallow cuts in a consistent location or randomly spaced on the panels?
It seems everything matters and as soon as one assumes its AOK, some new gremlin arrives.

[knight_toolworks]

no none of those. one part was right the next off and the next on. but the control software showed the depth was wrong. the toolpath was showing .77 all the time but the display was showing .64 thats what really threw me off.
I zeroed from the table. what really showed on the parts before the inside cut would be right the outside was not deep enough. the cut was inside then outside with one toolpath. but the depths were different.

[beacon14]

How did you make the toolpath? I had similar incident a couple of months ago where in one particular file the screen depth, toolpath depth, and actual depth did not jibe. Ran the file multiple times and it happened the same way each time. I changed the ramp length and regenerated the toolpath and it worked fine. Only happened one time and it was so bizarre at the time that I was starting to doubt myself.

[knight_toolworks]

I used vcarve and it did it on the same parts. till I unselected the part that cut at the right depth then it changed the parts that were not cut deep enough.
just checked the file. I made two paths one at .65 depth one pass so it would not show any errors and the second was at .77 depth full pass. with a 1" ramp thats what I have been using.

[gabepari]

Steve, was your z-axis bottomed out. I've have something similar happen after raising my z-car and then using a REALLY short bit. The pinion on the z-car hit the stop. It was only there for a short time, so the software didn't fault the driver. But it did exactly what you say, toolpath said one number and control software said another. As to why it happens intermittently, I don't know


I have also had weird-nesses that I can only attribute to certain combinations of numbers that the software doesn't like to calculate (addition of errors in decimal expansion and roundoff??). I just re-path with everything shifted over a few thou and everything is dandy.

Good Luck,

Gabe

[knight_toolworks]

no had plenty of headroom. I have had to battle that for really tall things so I learned to cope. recalculating it changed where it did it when I left a few parts out. I could not move anything because the holes and dado's were already done.

[ljdm]

Probably not the same issue - I had pretty close to the same problem, it was due to z-axis binding. It was just a little too tight where it only affected certain places where the rollers would bind too much. Cuts above or below that area on the z seemed ok. Z must have been worn in one area more than the rest, and if adjusted for play was done in that area, it got too tight in less worn areas. Definitely caused z depth problems, usually not cutting deep enough. My 2 cents.........

[gabepari]

Steve, if the problem moved when you changed the pathing, I bet it is software related. I've found a few combinations of move commands, where if you send the machine to a specific spot, then try to move to another specific spot the software crashes. If either location is changed by only a few tenths (10ths of a 1000th) then everything is happy. My guess is there is some calculation embedded in the control software that with the right (or wrong
) combination of numbers ends up with a division by zero or some silly thing.

It is extremely rare, but I've seen it happen more than once.

Gabe

[knight_toolworks]

seems it is a software glitch. I had it happen again and I moved the vector just a tiny bit and it cut at the right depth.

[gabepari]

Steve, this isn't going to sound right, but I'm glad you had this problem
I thought it was just me.

Gabe

[knight_toolworks]

no I understand. too bad all of these toolpaths are new. it would have been nice to compare the two control software versions.