Rob, I can post all ops at once using any other posts. Just not using this one particular one. Yet in X3 I can post all ops using any of my posts, and they all work fine.

Jim, I just ran through updatepost.dll via John's directions in the sticky, and I still have the same issue.

If I select a different machine, all operations post fine. If I open the same file (an older X3) in X3 all operations post with the okuma post fine, just not in mu3. I could get some operations to post by doing them one at a time, but it doesn't always work. Yesterday, I posted each of 15 ops as seperate program names to get around the problem, but I also had to set all planes the same in order to get my A axis positioned ops to post.

I updated to mu3 when it came out, and had no issues until yesterday. It was my first time posting a program for the okuma with mu3. The tool paths would only partialy post, or not post any code at all. It seemed to be relative when using different t-plane than wcs, but upon further testing, I have seen where one of three toolpaths won't produce code, even when all planes are the same as the wcs. All of my other machine posts appear to work fine. Any help is apreciated. Thanks, Tom

Sorry, I forgot about the necessary SCREEN REGENERATE DISPLAY LIST (SHIFT+CTRL+R) which I need to do after trimming....My bad

When trimming 1 entity, It appears as if I have it set to break instead of trim, but I can not select the line that is left. It almost appears to be a "gohst" of the origional untrimed line. Trim 2 has no issues, but I quite often use trim 1entity. Has anyone else seen this?

Thanks! I had the inverse ox toggled, and that took care of me. Thanks for the reply!

I read the post "Mpmaster for X3 avail / X2 to X3 changes." And did what was discussed, and it work excellent for 2d and 3d tool paths. But I still get F1000. on my 4 and 5 axis toolpaths when using feed rate advanced control. Has anyone else had this problem or know how to work around it? Thanks

I'm wondering if anyone can help me output my feedrate as "VC52" instead of an actual feedrate. I want my program to output "VC" when at 100%, VC52*1.5 when at 150% and ect. We're trying to utilize our common variables for feedrates on larger programs.

I see it too...

If you use your solid to verify with, you can also create a copy of your solid at the given translation distance, and add a larger solid body under both solids connecting them. But in this case you would have had to created duplicate sets of tool geometry also at the same distance. Inorder to verify properly.

We just tried some Schunk milling chucks and tribos extentions this week for the first time, and were pretty impressed with it so far!

The first thing I would look at is the drive coupler from the servo motors to the ball screw. If it's still a lovejoy (rubber) coupler, then stay away!

Thanks John.

I'm also trying to change the width of the cells for longer tool definitions, and I don't seem to be coming up with any results. Any help is greatly appreciated. Thanks, Tom