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.

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.

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.

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.

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.

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.

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. 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.

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.

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.

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.

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.

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.

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.

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?