On 4/20/2024 at 12:47 AM, Tommy Thompson said:

We have a number of fanuc controlled vmcs from various machine tool mfgers. Most are oi-mf. The machines are generally great and the controls usually perform well but our shop is struggling to load the new high speed machining tool paths or multiple programs for part arrays onto the fanuc machines. Without engineering know how, adding memory or ftping or getting a control to recognize a cf card in an adapter to a pcmia port (must be the last place on earth for such a thing) is all extremely time consuming and frustrating. The tiny memory on the average fanuc control is hard to understand. I’d like to know why they do not just put a tb of memory on these machines or make them connect easily to a computer. It seems like it takes patient dedication or an cs degree to make them work. Endless nuance about partitioning cf cards, etc.,embedding ethernets. It might be fine for a large firm or some of the wizards out there, but for the average job shop, it’s a failure. If you are an engineer who speaks fanuc and wants to earn some money please let me know. If you want to say it’s a piece of cake, save it bro. 

If your machine is less then 20yrs old it should have a PCMCIA slot. You just need to change the comm. port on the control to use it instead of RS-232. If they don't it's easy to get the cable and slot. You can either buy a new bezel for your screen that has a spot for the card slot or you can probably make a hole in your existing bezel. Change a couple parameters and you're good to go. I have 1 horizontal mill with only 64kb of storage so any HSM toolpath has to reside on the memory card.

However, to edit any toolpath on the card requires putting it on a pc, so if you want to be able to change the feedrate or maybe tool diameter offset if there's a CDC pass on the card you can substitute the F or D value with a variable#. I.E. if you program for F40, change it so it's F#500 (assuming you have extended variables, if not you can use #100-#150) then in your main program that's in the control you just need to insert #500=40. on the line before the M198. It's great for proving out 1st time run jobs to give the operator a way to edit the prg w/o dragging me to the floor for a simple edit like that.

On 4/20/2024 at 6:21 AM, Leon82 said:

does m198 work?

 

it works on our 0 control feeler pallet machine.

 

we use under 500 MB cards they don't like the bigger cards

 

I got this from james

 

Set the machine into "MDI" Mode.
Press the OFFSET/SETTING button.
Change/Set the “I/O Channel” to “4”
Set "Parameter Write Enable" to "1"
Press the Cancel AND Reset buttons simultaneously. This will clear the alarm you get stating parameter write is enabled.
Press the "SYSTEM" button.
Press the numbers "138" on the key pad then "NO. SRCH" on the soft keys (below the CRT). You'll need to set bit 7 to a 1 (Bit order is as follows - 7 6 5 4 3 2 1 0 - so you'll want to change the furthermost bit to the left to a 1)
Press "3404" on the key pad then "NO. SRCH" on the soft keys. Arrow over to bit 2 (3rd bit from the right) and change that to a "1"
Press "6005" on the key pad then "NO. SRCH" on the soft keys. Set Bit 0 to a 1.
Press "6030" on the key pad then "NO. SRCH" on the soft keys. Change it to "198".
Press the OFFSET/SETTING button to get back to setting and set Parameter Write Enable to a "0". Press Reset.
Now, this will allow you to run directly off your memory card.
Your main program in your machine control will just need to look like the following;
%
O100(MAIN PROGRAM)
M198P1234
M30
%
Optionally, you can add a Q to the M198 Pxxxx line (M198P1234Q101) and it will jump to that line number within the Sub Program.
Your program on the memory card MUST be named Oxxxx (the exes being a 4 digit number that MUST correspond to the actual Sub Program Number in the sub program. (ex. O1234) with NO file extension.
Your program on the memory card must be as follows (making sure the M198 P call AND the O number AND the Sub Program Number match as I've shown)
%
O1234(YOUR PROGRAM NAME HERE)
(YOUR PROGRAM AS NORMAL)
N101
M99
%
You MUST have a memory card in the slot when “M198” is called or you will get an alarm.
NOTE:
You’ll need to have the following on hand as well;
• USB Reader/Writer for your PC so you can load programs to the Compact Flash Card.
• PCMCIA to Compact Flash Card Adapter so you can load programs from the Card to the machine.
• 1MB to 1GB (MAX) Compact Flash Card. The smaller the capacity, the more likely it will be compatible with your machine.

 

All of the memory cards we use are 512MB or more. Most are over 4GB and we had any problems in the 10+ years we've been using cards this big Our oldest control in an 16i control from early 2000's and no problems there. Just have to watch the formatting. We have 2 machines that have memory cards that pretty much live connected to the controls.

Yeah, it's the one thing that always irked me when only posting a few operations and the post is set to auto number planes. The 1st operation is always G54 regardless of what it posted as when you post the entire program. Been burned by that a few times, so that's when I started putting a value in the plane manager any time more then 1 plane will be used and this was 20+ years ago. For the most part it wouldn't make a difference 'cause usually when I only select individual operations I'm only looking for the toolpath itself so I just paste the changes, but when I add a toolpath on another plane and paste that whole toolpath in, that offset value is gonna bite ya.

For what I know about posts, it was obvious to me that the -1 was more like a trigger to the MP to determine how many different planes are used and to assign a new offset value to each one. This is probably the easiest way, but can also burn you like in my instance above which is why in my 5x posts I have it set to always use G54. All of my horizontal mills have Fanuc controls and none have dynamic offset so I made myself get in the habit of manually assigning an offset to every plane. I can already program crashes enough on my own, I don't need any help.

Thanks for the help and education Colin.

19 minutes ago, Colin Gilchrist said:

Glad you found the error.

Technically, I think that entire block could be deleted, and the 'call' to 'pworkofs' could be replaced with the line 'workofs_out = mi5$'.

The reason I say this is: the value of 'workofs$' variable never gets set to '-1'.

Users (post developers) used to think that "-1" meant that automatic work offset numbering is enabled which is technically true, but the variable 'workofs$' always gets assigned a value, starting from '0' and counting upwards. The variable is never stored with a value of '-1'.

The '-1' value is stored internally in the Binary NCI, and during the ASCII NCI Conversion process, the value of 'workofs$' will be assigned "the current work offset value, or if the plane changes, it will be automatically assigned the next available work offset value.

 

Yeah, after looking at it and running it thru my head I was thinking it could be deleted as well.

I suppose that you could make the workofs_out switch in the post setup section like an off/on enable/disable switch for automatic plane numbering with a 0 or 1 you could accomplish the same thing. A 0 would disable auto plane numbering and the post would either always use G54 or use the value in plane manager. A 1 would enable auto numbering and would ignore any value in plane manager and increment each as it's used by 1. I suppose if you wanted to add more control you could add some logic to the post that would say "If workofs_out = 0 and  value in the plane manager is equal to or greater then 0 then workofs$ equals value in plane manager , else workofs$ equals 0. Which is already in there for the most part except it doesn't look for a value in the plane manager.

Seems as -1 was an easier way to how to control workoffsets, but again I'm no post genius.

16 hours ago, BBprecise said:

Colin, here is my pworkofs block in my post.

pworkofs        #Find current work offset separate from output for use in ptlchg0, etc
      if workofs_out >= 0, workofs$ = workofs_out
      if workofs$ = -1, workofs$ = 0

 

Thanks.

So in pworkofs I changed the 1st line to

if workofs_out >= 0, workofs$ = mi5$

and so far I haven't seen any odd behavior or unexpected moves.

On 11/17/2023 at 9:11 AM, Colin Gilchrist said:

Yes, it could be that simple, however I'd have to look at the structure of the Post to be sure.

For example, in the block above the "if" statement logic conditions, there is a call to 'pworkofs'. I suspect there may be logic there which is manipulating the value of 'workofs$'. Also, we need to take advantage of the condition 'workofs$ <> prv_workofs$'.

Try testing this out:

pwcs            #G54+ coordinate setting at toolchange
      if wcstype = 2 | wcstype > 3,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = 0
        pworkofs

         workofs$ = mi5$
        if workofs$ <> prv_workofs$ | (force_wcs & (toolchng | retflg)) | sof,
          [
            if workofs$ < 6,
            [
            g_wcs = workofs$ + 54
            *g_wcs
            ]
          else,

Also, Copy/Paste your 'pworkofs' block so I can take a look at what is going on in there.

Your edit induces the same behavior mine did. Hmmm.

So after some testing, my edit resulted in some unexpected behavior. Now between every operation Mastercam/Post processor seems to think I want a mid op retract as it sends the Z home unlocks the rotary axis's, positions them (which seeing both operations are in same plane nothing would move), lock the rotary axis's and posts the next operation.

On 11/17/2023 at 9:11 AM, Colin Gilchrist said:

Yes, it could be that simple, however I'd have to look at the structure of the Post to be sure.

For example, in the block above the "if" statement logic conditions, there is a call to 'pworkofs'. I suspect there may be logic there which is manipulating the value of 'workofs$'. Also, we need to take advantage of the condition 'workofs$ <> prv_workofs$'.

Try testing this out:

pwcs            #G54+ coordinate setting at toolchange
      if wcstype = 2 | wcstype > 3,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = 0
        pworkofs

         workofs$ = mi5$
        if workofs$ <> prv_workofs$ | (force_wcs & (toolchng | retflg)) | sof,
          [
            if workofs$ < 6,
            [
            g_wcs = workofs$ + 54
            *g_wcs
            ]
          else,

Also, Copy/Paste your 'pworkofs' block so I can take a look at what is going on in there.

Colin, here is my pworkofs block in my post.

pworkofs        #Find current work offset separate from output for use in ptlchg0, etc
      if workofs_out >= 0, workofs$ = workofs_out
      if workofs$ = -1, workofs$ = 0

Thanks.

2 hours ago, Colin Gilchrist said:

By the way, you can use the Control Definition to edit the "displayed text" for MI5, so it tells you when you go into the operation, what that Misc. Integer is used for. (Technically, as the Post editor, you are telling the user what that control is used for. You may be both the editor and the user, but if anyone else uses the Post after you, or you do a bunch of other work on other machines, and come back to use the Post months later, having the 'label' for MI5 in the operation will help.

Yeah, I've already edited the Control Definition. I've used Integers and Reals for other things in the past.

Thanks for the reminder though.

2 hours ago, Colin Gilchrist said:

Yes, it could be that simple, however I'd have to look at the structure of the Post to be sure.

For example, in the block above the "if" statement logic conditions, there is a call to 'pworkofs'. I suspect there may be logic there which is manipulating the value of 'workofs$'. Also, we need to take advantage of the condition 'workofs$ <> prv_workofs$'.

Try testing this out:

pwcs            #G54+ coordinate setting at toolchange
      if wcstype = 2 | wcstype > 3,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = 0
        pworkofs

         workofs$ = mi5$
        if workofs$ <> prv_workofs$ | (force_wcs & (toolchng | retflg)) | sof,
          [
            if workofs$ < 6,
            [
            g_wcs = workofs$ + 54
            *g_wcs
            ]
          else,

Also, Copy/Paste your 'pworkofs' block so I can take a look at what is going on in there.

I'm out of the office all of next week and been running machines today so I'll get back to this when I get back.

Thanks Collin.

So I put workofs$ = mi5$ in my post here and it seems to work correctly for a simple drill toolpath anyways.

pwcs            #G54+ coordinate setting at toolchange
      if wcstype = 2 | wcstype > 3,
        [
        sav_frc_wcs = force_wcs
        if sub_level$ > 0, force_wcs = 0
        pworkofs
        if workofs$ <> prv_workofs$ | (force_wcs & (toolchng | retflg)) | sof,
          [
            workofs$ = mi5$
            if workofs$ < 6,
            [
            g_wcs = workofs$ + 54
            *g_wcs
            ]
          else,

Could it really be that simple or am I missing something?

Thanks.

Colin, yes G54 is always my locked work offset. If I put workofs_out as -1 in my post, I will get a different offset for every plane which can be a lot. Only way to change that would be to manually put a 0 in the offset column on plane manager for every plane which because we typically only ever have 1 station on the table is a nuisance. Hence why I have 0 in my post. I want to leave the post behavior the way it is so I don't have problems with previous files among other things.

I'll see about adding  logic to 'pwcs' to use mi5$ and how I want to do it numbering wise.

Here goes nothing.  

Hey Jon,

Status would probably have been a better word to use instead of value.

In the post setup switch section of my post, workofs_out is set to 0 which forces the post to always use the G54 work offset to keep MC from using a different work offset number for every rotation. This works 99.99% of the time as I usually only have 1 station on the table at a time. On my current part we'll have 3 stations/operations set up on the table at the same time.

With the way the post is now it will post out G54 for each station which isn't what I want. I want to do G54 for station 1, G55 for station 2 on so on.

I was hoping that I could set the status of that switch using a misc integer. Say I put a -1 in mi5 the post will use whatever workoffset I've assigned that plane/view in MC plane manager or if I put a number it would use that number as my work offset. I prefer to use the former so I don't have to worry about setting mi5 in every operation.

Hopefully this explains what I'm looking for better.

Is it possible to set the value of workofs_out in a post processor to use a misc or real value?

For the last 20+ years we've been using Cimco. But before that we used a program called Quicklink. We used Quicklink when our programming pc was running windows 3.x and Quicklink was a DOS program. Simple but worked.

Only have 1 machine left that uses RS232, the other 20 or so use either memory cards or thumbdrive.

On 5/25/2023 at 5:33 AM, Thad said:

In over 20 years of using MC, I've never used tip comp and breakthrough. I couldn't care less what page that setting is on, or if it even exists at all.

Doing die work, we do a lot of holes that start and end at different Z depths (inside pockets, keys, break into pockets/steps on the other side, etc) so I change back and forth from absolute to incremental multiple times per day. I also copy and reuse toolpaths all day long. So if you think Abs/Inc is changed "almost never," you're wrong.

I'm with you, I've been using MC the last 15yrs dead ahead every day, before that I bounced in and out of programming to be close to 20yrs of using MC and I don't even remember when tip comp was introduced.

Besides why have a complete page dedicated to doing the exact same thing as the little calculator that has been under the depth field in a drill cycle? Only difference is that the user has to add/subtract the amount they want to break thru manually instead of entering it in a field.. And it's not like you can leave the tip comp enabled so it's active for every drill toolpath cause sometimes you just can't drill deeper and MC can't tell the difference between selecting the back edge of a hole or the full dia. depth of a hole. All MC see's is a point to use as a depth.

I never understood the intent of Tip Comp page anyways. Maybe just to old school and stuck in my ways seeing as I started on ver. 5.5.

Yeah, the material is 17-4ph condition 1025. By far not the worst stuff we machine, but not exactly aluminum.

We're still looking for a more fool proof way to measure the slot, but haven't found anything yet.

8 minutes ago, Colin Gilchrist said:

RMP 600 is a Strain Gauge Probe, not kinematic arrangement, and is far more sensitive than your machine is capable of holding. Accuracy/Repeatability should be on the order of 0.25 Microns to 2 Sigma. That is 10 Millionths.

Make sure you calibrate with the new Stylus (I'd use a 1.5mm or 2mm max. diameter ruby or silicon nitride ball, depending on material being machined).

When you use the "tool wear adjustment" Macro, there is typically an "experience" value. This is poorly-described, but is essentially "the adjustment percentage of the measured deviation between actual and nominal".

You use the Experience value to adjust the amount of "change being made" to the wear adjustment. For example, say you programmed a 2mm cutter to make a Semi-finish pass, on both sides of the slot, leaving 0.1mm per side. This should give you a 2.8mm wide slot. But when you measure the slot width, it is 2.784mm. The difference between nominal (2.8) and actual is 0.016mm. We could then correct the Wear Offset (assuming radius, in this example), by 0.008mm, so it cuts that much additional metal off each side of the slot.

Except in practice, other factors such as tool deflection come into play. Through "experience" you come to find that using between 60-70% of the 'delta measurement', gives you more predictable results in production, to avoid overcutting when making the final finish pass. You could use an "E" value (may be a different Alpha-Address Character), of E0.65, which would tell the Macro to only use "65%" of the delta value.

I will typically use an Experience value of 40%, if I'm doing a multi-step process with the probe to qualify a tool. I find I get the best results by "sneaking up on the adjustment", and then re-cutting the Semi-Finish Pass (again, using 40% as a starting test value).

If you are taking the approach of automating the process, it will be very important to calibrate often, and to be sure the probe tip and the slot is very clean, and that the machine is warmed-up, using the same cutting program that will be run in production. (Don't put "too much heat" into the machine, it needs to be as close to actual "operating temperature" as possible.)

 

I believe we have a 2mm ruby probe for this slot. Originally they were only using the probe to set the orientation of this slot on a future operation.

I measure the width of the slots in 5 spots because I was trying to catch any deviation in the width of the slot so right now so I'm adjusting the tool diameter with a macro. I've never used the experience value so I'd have to look in to that some more if I'm able to use the built in slot width measuring routine.

As they say, the only way to know for sure is to try it.

Thanks.

25 minutes ago, crazy^millman said:

Need to do a gauge R&R and determine what is the true accuracy of the machine. That means running hundreds of checks not one or two. Most CMM's have trouble measuring that tolerance and you trying to take a probe on a machine and do this? What are the underlying most important factors for the machining environment? Temp, Tool, Work holding, Tool Holding, Coolant, and many other factors for this process? I know of customers holding this tolerance with manually process on Mazak's, but with a probe I would need to do as I stated a lot of testing and proving out before I could trust a process holding something that tight with an endmill. Now if you are using a High Speed Head and trying to grind it in then that is a completely different conversation.

I have a test program to machine the slot the exact same way we do the part which is to rough it w/in .005 per side with the roughing e.m. Then the finish e.m. mills it to -.0015/side before it stops to allow operator to measure the width. Then the program opens the slot to finish size in 3 more passes with an M0 between each .0005 pass for the operator to measure. I added probing before each M0 and left the M0's for the operator to verify size. I expect to have to run the program several times before I'm comfortable enough to say it will work every time. If it will even work.

The problem we had with the pins is the day operator did just fine, but the night shift operator said he couldn't get the low pin in at finish size so he opened it up and blew several parts oversize. We're still looking for a more fool proof way to measure these slots but nothing I would trust better then pins yet.

41 minutes ago, #Rekd™ said:

Is the machine capable of holding that tolerance? 

Yes. We've machined these parts before. The problem before was operators were only using gage pins and one operator apparently had a better feel and was able to hold that tolerance. We're researching better methods to inspect the width, but so far our options aren't much better in my book.

I haven't done much lathe programming lately, but when I do need to rough the part I use the roughing cycle and it always leaves me the correct amount of material. Always. Using equal steps tells Mastercam I want the doc's to be as close to this amount as possible but I also want the doc's the same amount. If you're getting to much material left on reduce your min. cut depth. I have Mastercam set my default at .015" and I can't say I've ever noticed it not leaving the right amount w/in a couple thousandths anyways. If The finish tolerance is +/-.005 or more I don't care about a few thousandths extra. Tolerance down to +/-.002 then do 1 sizing pass and a couple extra thousandths on the 1st pass won't change cut diameter noticeably. Tolerance tighter then +/-.001 and we do at least 2 sizing cuts and a few thousandths wont bother here either.

Now when cutting Inconel, Rene, Titanium and some hardened ph series stainless (only if we cant control the time/length in cut good enough with a general roughing cycle) we create geometry for every depth, but only to control the time in cut and the entry/exit method so we don't leave sharp corners that with notch a ceramic insert in Inconel and Rene instantly.

We have a few fairly new Mazak Integrex I series 5x machines with RMP600 probes. I was wondering if anybody here has had any luck measuring a 3mm wide slot with +/-.0002" tolerance with a probe and adjusting tool diameter to machine the slot in tolerance?

I've made a test program to try before we try it in the actual part, but I'm just curious what success others have had in trying to do this.

Thanks.

To understand you better, you need to balance a part and keep it's weight w/in a certain range? And you do this by cutting 1 straight wall on the part?

I assume you are taking the part out after every pass you currently make to weight and balance it?

I think it would come down to how accurate your balancing device and scale is and if your balancing device has any kind of scale on it. If you can find a correlation between how much the weight is off compared to the balance of the part I think you probably could.

Lets say your part is 1 ounce to heavy and you've determined that removing that same 1 ounce will put the part in perfect balance. You can calculate how much material you need to take off that wall to remove 1 ounce. You could just make a chart that would tell you how much to reduce the tool diameter by to remove the 1 ounce or you could make a macro where you can either put say #700=1 (where the number after = sign is how much weight you need to remove) and you would edit this number for every part or you could manually change #700 in you macro variable table so you don't have to edit your program. Then you add some macro code to calculate how much material needs to be removed and adjust the tool diameter. With either method you would want to reset your tool diameter back to nominal after every part (which can be done thru code) so that you don't accidentally cut to much material off on the next part.

More info and pics of the part and the edge you cut would be needed to get a better idea if this would work for you.

On 3/25/2023 at 4:44 AM, Newbeeee™ said:

Being UK we used Control 100% for finishing paths. By the time I read about wear, we had a load of new progs and Bus.Partner wasn't happy about changing as he never saw the benefit

But the lead-in-out I set to 55% default. I'm sure initially, it was 50% but on a part (or two) we got the fanuc comp alarm. 55% cured it and we never had a problem again.

Same here. I haven't run in to a situation where I couldn't make control work in almost 28yrs. Maybe I'm just lucky.

By default my lead in/out are set to 55%. I have had times where I've had to be between 50 and 51%, but that's very rare.

7 minutes ago, #Rekd™ said:

I think it has more to do with the chip in my test being a 12th generation chip, most of the faster times have been on 12th generation chips.

I'm sure it is as newer chips are usually more efficient. Not sure if 2021 helps or not as I know that I've seen newer versions have slower processing times.

I'll probably just stick with my i7 as the battle to get it swapped out to an i9 is probably more then its worth.

8 minutes ago, #Rekd™ said:

The system in my post above is a Dell 3660.

I was wondering if it was. Looks like you're roughly 30sec faster then my 3650. Not sure if it's worth complaining to corporate to get them to replace mine with a 3660 or not.

I did a regen on a stock model yesterday from a part I finished a few weeks ago and it wasn't a whole lot faster then the i7 2700k I had o'clocked to 4.2ghz system I had with 16GB of ram and a P2200 Quadro.

Seeing you have a k processor maybe you can answer this. Does Dell give you methods to o'clock the processor in the BIOS? Or are you relegated to software that will do it thru Windows?