Install the new release separately. You can reopen an X2 MR1 file with plain X2. We've had several issues so I just went back to X2 to finish the job. Works fine. Note: when I get the time I will submit the problems to QC... -- Bill

I just installed MR1 myself but I've found this to be an issue back with X and X2 when the number of operations starts to grow (100+). After using the file for a while, selecting several operations was almost impossible. Sometimes I could not even select one without trying several times. I found if I just quit MCX and restart, all was good again. Try it yourself an see if that fixes it. -- Bill

Roger you are correct it seems. While entering the radius field in the undefined tool generates the correct toolpath (at that moment). It then goes back to zero corner (and offsets the tool accordingly) if the operation is regenerated... -- Bill

Reply to self... To get the terminology correct: I created an "undefined" tool using a ref mcx file. I forgot to enter the tool radius into the field. That said, once entered the field goes back to zero once saved and recalled. Seems to work now so... onwards we go! -- Bill

I've defined some custom tools to represent 3" dia shellmills using round button inserts. In the custom tool/diameter value I have 3.0. The tool is kellering a large angled slope. It seems to drive on the theoretical corner of a 90 deg mill which means the tool is not tangent (touching) the drive surface. I changed it to a standard bullnose e/m and it works fine as expected. My question is then, can you drive a custom defined tool to its tangent cutting edge? We're considering an all custom tool approach for data management reasons. -- Bill

Is this issue being worked on now? We have weldments that are comprized of many welded with small gaps (weld clearance) that are imported. -- Bill

Ron, Thanks for the help. Yes, we use misc values (I think that's what you meant by mi?)We put our work offset and W axis positions there now (special TC macro...). It's not a deal breaker to not have a field in the operation. I'll play with the post later during lunch. The only down side is some users here "forget" about that area when copy/pasting ops. I'm sure you agree, when there are a 100+ ops and folks need to do quick changes... It pays to be a simple as possible. -- Bill

Roger, I'm retracting above the slot to clear then moving. The G99 insures a rapid back to the engage point. I'm not currently feeding between holes. The scenario would be a field for "rapid feed rate". By entering a value other than 0, the post would then output a G80 and fresh G8x for every hole thereby allowing a G1 between holes. It would be seamless to the programmer. Rick, "Some" machines here could be set for no "dog legs". The issue is to keep the MCX file generic enough that the program can be easily reposted for different machines. We're trying to standardize the process for most programming issues (and it's killing me... ). -- Bill

Rick, Yes, that is what I'm doing now. I retract using G99. It works ok. In the end we go through our programs tool by tool and operation by operation to sqeeze out waste. Our parts large, long term production on large machines, hence anytime we can reduce the air moves the better. Btw, I passed this on the QC as an enhancement. Other systems have it, we should too. -- Bill

Ron, Thank you very much. Regards, -- Bill

"I don't understand why something that is very out of the norm is a "workaround"?" Perhaps to some, very out of the norm... For me it's drilling a series of holes down in a long diagonal slot. The slot is 1" deep and the hole spacing is such that the dogleg would send to tool into the sides on rapid if I keep the R plane close. That said, I came from a system that had a simple field to set a feedrate for rapids within each operation. It allows one to use a fast G1 for true point to point just on that operation. Just something I was used to... -- Bill

I was hoping for the simple "Rapid Feedrate" field in the operation. I'll just retract all the way out as a work around. -- Bill

Is there a setting to change the default rapid of A SINGLE OPERATION to a linear feed? The purpose is for preventing dogleg moves for that op only. The operation in question is a drilling op. TIA. -- Bill MCX 2

One of my requests has been for a "real" undo function tool. It would affect not only geometry edits but OM edits as well. There would be a dropdown listing of the changes by order so you know which thing your undoing. This funntionality has been available in other systems so I see no reason MCX shouldn't have this ability as well. -- Bill

I've had this happen twice myself (as was mentioned in an earlier post). I haven't been able to recreate the disappearing act. All I can attribute it to is the operation manager does quite a workout when copy or cut/paste of operations. It's a bit un-nerving to watch the operations blanking out during the process. Also tied to that is when you first load a file it can take what seems like an eternity for all the operations to load under the groups. ring operations scenario either. -- Bill

Peter, Sorry, I didn't see this thread still going... You may be right in that it's as designed because of the step over amount. That said, in a previous life, the system I used would know that and not step over where it can't but would where it could. No worries. -- Bill

There's a another one of these beasts here around L.A. http://www.marvineng.com/adi/pics/product_c.htm I used to program parts on this one. Come to think of it, the parts in the foreground are ones I did some rev changes to. The reality is that most times we had each of the 3 bridges doing different parts in the 6'to 12' range in sets of 3. Being each head has 100hp there's quite a rooster tail on some cuts! -- Bill

Without a doubt, plungemill. -- Bill

I just used closed pocket/start point. Moving on... Thanks all. -- Bill

John, I'm going for the day (finally) but... draw a simple shape where the main shape is wider than the opening of the pocket. Perhaps that is the issue? -- Bill

Kannon, The cutting style is locked when using open pocket. Kyle, Use start point on open pocket gives the "can't cut island boundarys (or somthing like that) which makes sense. John et all, I sent the file to QC but it's occurred to me that really the purpose of Open Pocket is to allow one to define a pocket boundary with an open side (hence the overlap value adjustment feature). Perhaps it's not designed to nessessarily start at the open end. It's just for selection purposes? We'll see. -- Bill

John, Thanks for the help. Can't really send the file (hush hush and all that...) but I will try more later using different curves (and the machine is not waiting for my program). -- Bill

Yep. Pocket Open, "Use open pocket cutting method"... I used closed with a start point to get it done. Still, it should have worked. -- Bill

Simple bottle shaped chained 2d curves using "Pocket-Open". The small end is the opening. No matter how I slice it or dice it, the tool wants to plunge into the large area of the pocket then finish at the narrower open end. The tool is a 3/4" EM. The narrow end of the pocket is .875 wide. The widest area is 2.5" across. S/B plenty of room to enter from the narrow area without having to plunge into the part first. What gives? __________ |--------- |----------__________ | * Plunges here ------- <-- Open here |---------- __________ |----------/ |---------/ |________/ -- Bill

I've had the same problem Twice now. The first time I hide the OM and did some drafting then saved. When I unhide the OM all the (150+)operations were gone. Only empty toolpath groups were left (which tells me I didn't hit the delete all operations button). That was on X1. Just this week on X2 it happened again, I just opened an existing file... only the toolpath groups were left. I waited a couple minutes to be sure. There is quite a delay in filling the toolpath groups with all the ops on open. This is regardless of network or local file locations. I use the backup function (not autosave). Your not alone. -- Bill