did not show in verify or backplot

[cherokeechief79]

have you ever had something post but did not show in verify or backplot?

once in a while this happens but it always seems to be while using engraving.

[#Rekd™]

On a Fanuc control yes.

[Matthew Hajicek - Singularity]

That's what Vericut is for.

[#Rekd™]

Didn't show in Vericut either!! CGTech sent a guy in to investigate at the time, after all was said an done they issued a software update. It was a min arc issue.

[cherokeechief79]

thanks for the reply.

we use x8 in school because its all the laptop we use can handle.

we were running an engrave prog on a project  and on one of the very last moves the machine made a horrible rapid like move,

ruined the part and alarmed out the haas we were using.

I looked at the code and there was an arc at the end with an I of 560.9079 and a J of 2094.4913.

I single stepped it back in mc verify and saw no arcs in the area it did it in.

also the backplot and verify showed nothing out of the ordinary.

even watching the commands I saw no arcs.

I noticed the default parameters in the filter box were set to 0 and 2500.

I changed them to .005 and 200 and the arc in the code disapeard.

if the haas could not process an arc that large shouldn't it have alarmed out at least with an overtravel before it attempted to contour it?

also the machine took off as if it were in a rapid move as it did this even though the last command was a g01.

of course this all happened on the last move on a students project we were working on with the whole class looking on!

[cherokeechief79]

the only thing I think it could have possibly been was the geometry we were cutting had to be shrunk way down to fit.as we did this we got a couple of warnings about zero length line.

I guess we scaled it under the max it could be scaled but it did chain ok and it didn't have any breaks.

maybe there was something left that could only be picked up by the max rad tol of 2500 in the create arcs box?

[Jayson Kramer]

Are you talking about actually using the Engraving toolpath option or you did simple engraving using contour?

[cherokeechief79]

no contour. we used the engraving toolpath

[Guest]

The arc size should not have mattered...

I have seen plenty of times where a large arc value is put out but the segment is only a small portion of the full arc.....

Typically, arcs that loop like that are an end point issue/start point issue with the arcs......when the end & start point don't coincide, the control cannot properly calculate the arc and will tend to run a big loop, this loop will never been seen in Mastercam.

This is most likely a control def issue with the arc tolerance or not breaking arcs when they fail.....

[cherokeechief79]

I tried 3 other posts that came with mc and none of them ouput the arc at all.there must be something in my post doing it.

any idea on what to change?

my post is custom made by prism eng for ver 9 years ago.

[Guest]

A Haas post....

Why not just switch to a newer post that comes with X8....Haas is pretty good right out of the box....

That post at this point is at the very least 12-15 years old.....

Edited April 5, 2017 by Guest

[Jim at Gentex]

11 minutes ago, cherokeechief79 said:

my post is custom made by prism eng for ver 9 years ago.

Might be a good time to have your post updated if it is a custom post.

(In case you haven't heard, Prism Engineering is now Fisher / Unitech.) 

Chris J. is still there doing Mastercam tech support, and in fact I was just talking to him yesterday.  He will dial that post right in for you if that's what you need. 

 

I had a weird issue with a multiaxis curve toolpath on our Haas VF5 a while back that was similar to what you are describing here.

The tool would get to an arc near the top center of the part then just start cutting off on a tangent right through the part.  The tangential move never showed on the backplot or in machine sim, or in the code.  I thought since the arc in question was near the intersection of the rotary and tilt axes that it was a singularity issue caused by that intersection point.  After a bit of trial and error I ended up simply breaking the arc into 2 pieces and the problem went away.  Just another one of those weird things we come across in this line of work.   

[cherokeechief79]

thanks, we are getting training on the 5 axis by cimquest soon.hopefully they can fix it for me.

the post is custom only in the way that it treats subs.i worked with someone from prism yrs ago to perfect it and he finally got it perfect.

maybe now posts are as advanced as what we created back then.

I still don't know why this arc move took off in a rapid motion.

[Guest]

1 minute ago, cherokeechief79 said:

.

I still don't know why this arc move took off in a rapid motion.

Yes you do....bad endpoints

Without digging deeper, tough to say exactly where the issue is, post or control def but the cause is well defined

 

[cherokeechief79]

thanks john.

I did not realize bad endpoints would go in a rapid motion.

I figured the controller would alarm out.

[Guest]

4 minutes ago, cherokeechief79 said:

thanks john.

I did not realize bad endpoints would go in a rapid motion.

I figured the controller would alarm out.

Not that I have ever seen......it will run to the soft limit

[cherokeechief79]

ok so just a little update to this.

we had a very knowledgeable haas guy here to train on our umc 750.he also is a pro in mc.

I described what happened and he said he had never seen this before.

I reset the arc defaults in mc to .005 and 2500 and reposted it.

I put this in our vf 5 thinking it would do the same thing but it took it all the way through and ran fine.

then I put it in our newer tm2 with a newer control and ran it there.

rapid was at 5 % and the feed was slow.

when it got to the arc at the end of the program the machine took off so fast that there was no way to hit the estop.

the machine traveled beyond the software and even the hard limit and wiped out the springsteel waycover .

when the mach alarmed out it shut the servos down.

when I fired it back up the y axis lunged forward about a 1/2 inch because it had jammed itself past the limit.

he called haas and they said the problem was that the machine needed a software upgrade which he did.

now it just alarms out saying arc too large.

im not sure yet what the max size it will take.

this alarm is ok if it prevents this from happening again but im still confused as to why it ran fine on an older machine.

 

[Leon82]

I had a pocket where I changed a step over and it cut thru a center boss. Lowering the step overback to the original fixed it.

 

 

[Watcher]

Not exactly related but coarse tolerances in Vericut may not show a tiny cut, since Vericut cut tolerance is often tied to a tool diameter and contact area. Engraving tools remove small volumes of material and feature small contact areas. Vericut can be blind to small engagements depending on the cutting tolerance setting. 

By coarse tolerance I mean higher than 1mm. I'd like to reinforce that Vericut cutting tolerance is not measured linearly but rather volumetricaly, so a tolerance of 1mm is not measured in any specific direction - It represents a volume. 

[Colin Gilchrist]

Machines can be finicky with their software requirements. I believe the max recommended Arc size is 999. (It might be 999.9999, but I don't bother with the decimals.

Also, regarding the testing by posting with other posts; the Control Definitions can change the output pretty easily. In order to truly test, you need to run with the same exact settings. In the Posting dialog box, press CTRL + ALT + SHIFT + "P" on the keyboard. That will activate the "Select Post" button, and let you process with the exact same "input". (Toolpath settings + CD settings.)

 

[Matthew Hajicek - Singularity]

On 6/17/2017 at 0:25 AM, Colin Gilchrist said:

press CTRL + ALT + SHIFT + "P" on the keyboard

Good to know, thanks!

[Aaron Eberhard]

On 4/5/2017 at 1:03 PM, Jim at Gentex said:

The tool would get to an arc near the top center of the part then just start cutting off on a tangent right through the part.  The tangential move never showed on the backplot or in machine sim, or in the code.  I thought since the arc in question was near the intersection of the rotary and tilt axes that it was a singularity issue caused by that intersection point.  After a bit of trial and error I ended up simply breaking the arc into 2 pieces and the problem went away.  Just another one of those weird things we come across in this line of work.   

Hey Jim,

Just a note that might be helpful in this situation.  You're most likely right that it's a singularity issue, and of course, on a machine with real TCP, you don't care too much, but it can cause some big havok on those older machines without it.  The problem is that MachSim (by default) cuts as if you have TCP, so you'll never see it without some sort of G code simulation.  

Starting in 2017, you're able to simulate what it's like without TCP.

For example, here's a part that was ran through MachSim with the default settings:

Now we turn off TCP (and tell it to guess/fill in moves where there's a huge angular shift, I entered .005 & 120°), as well as turning off the normal "point interpolation" that it normally does to smooth out the display:

 

Let's see if you can spot the differences:

 

Hope this helps someone!

[Aaron Eberhard]

Oh, one other note.  By default, you won't see the move actually cut through in MachSim because it's normally set to NC mode, where it "jumps" from point to point.  It'll still display the gouge as shown above, but it won't play through it.

To fix this, use Time Mode or Length Mode instead of NC mode: