BACK POLT TIME ON X

[RObert TImby]

A QUICK QUESTION ABOUT X. ON X IS THERE A WAY TO GET X TO GIVE ME A EST TIME TO CUT ON BACK PLOT?

 

THNAKS FOR THE HELP!

[Guest]

welcome to the forum

 

 

on the backplot window there is a double arrow, click it yto expand the window, time is availabe there

[RObert TImby]

John

 

Thats for the help!

 

rob

[edmBosto]

Welcome to the forum Robert.

If you are using wire, the backplot clock isn't there. My reseller verified this for me.

[Mcam Nut]

I have a question on this topic, I program my taps using the pitch of the thread, and if I backplot with the tap selected, it will add around 3 hrs to the backplot est. time. Is there a way to set this up to be more acurate?

[Mcam Nut]

Bump

[Thad]

If I remember right, all drilling cycles gave faulty times. Drilling a few holes would take 8 hours, etc.

 

Thad

[Mcam Nut]

quote:

---

If I remember right, all drilling cycles gave faulty times. Drilling a few holes would take 8 hours, etc.

---

I dont find my drill cycles to be off nearly as much as my tap cycles, but is there a way i can set my backplot not to include any cycles in the estimated time, or do I just have to unselect all drill/tap cycles?

[Thad]

quote:

---

or do I just have to unselect all drill/tap cycles?

---

That's the only way I'm aware of.

 

Thad

[Storkman]

Thad......is that you?

[Thad]

No, it's me...Storkman.

[somename75]

So is the cut time given in ver 9 or X correct? I know that it cant acount account for toolchanges or rapids, but the time in cut should be pretty darn close I would think.

[Johan van de Loenhorst]

Mcamnut, if you fill in a feedrate and a spindlespeed in your toolparameters, it will give you a better time in backplot(when you give the right pitchrate, it will override the feedrate)

[Thad]

I'm obviously way off on this one.

 

I quit paying attention to the drilling times since they've been faulty in previous versions and haven't looked at them since. I also assumed that since MC can't show me a peck cycle (the physical pecks), then how can it give me a cycle time? I was wrong.

 

Thad

[Johan van de Loenhorst]

Thad, you are right about the fact that the times are way off, I used to rely on them in version 6/7. back then it was pretty accured, i could calculate on the backplottimes. nowadays...

[somename75]

I seem to be exceptionaly slow this morning. Is the time in cut accurate in backplot, or is it off because of the drilling?

 

Thanks for your help on this one

[Johan van de Loenhorst]

inaccurate to my humble opinion, both in toolpaths and in drilling.

 

Ive got a small fanuc, which is very fast in toolchange and rapid movements, as i told above in version 6 and 7 the backplot time and the machine time were allmost the same, only a few seconds of. in x its a few minutes of in a cycle of 10 minutes. x does it faster then my machine.

 

If anyone knows a way to fix this, please let me know

 

Johan

[Bryan Johnson]

quote:

---

I have a question on this topic, I program my taps using the pitch of the thread, and if I backplot with the tap selected, it will add around 3 hrs to the backplot est. time. Is there a way to set this up to be more acurate?

---

Yes. enter your spindle speed, and accecpt the feed as given in IPM. Modify the post to output the pitch and not the feed.

This will correct your cycle time proble, and automate the feedrate entry.

[Mcam Nut]

quote:

---

Yes. enter your spindle speed, and accecpt the feed as given in IPM. Modify the post to output the pitch and not the feed.

This will correct your cycle time proble, and automate the feedrate entry.

---

I was thinking about that, but the problem is that I have 11,500 programs, and aprox 75% of them have tap cycles. I am woried that someone will repost old programs (WTH do people do that? ) and the feed will be off, and the operator wont pick it up. I would rather be safe and not change it.

 

:EDIT:my taps in the tool library are actully drills discribed as taps.

[Bryan Johnson]

you could add an if statement to your post as follows so that it could handle both cases.

 

if feed > 1, *pitch, !feed

else, *feed

 

this assumes that the feed would never be greated than 1 if it represents thread pitch, and that the feed would never be less than 1 if it represents IPM.