You have been helpful, I have picked up a bit while working through this. My original logic addition to the post cured this behavior for this particular case, but, I have found that it does not eliminate the behavior entirely. It is showing up again in between some 5x Deburr ops as well, in spite of my "fix". Back to the mines...

You are correct, CYCLE800 is working as it should, and the calls are reflecting my inputs properly. For the sake of this conversation, ignore Ops 3 and 4. Just look at the first 2 ops and the resulting code from posting them. - Operations 1 and 2 are on the same plane. - Cycle800 rotates to the correct plane at the start of machining (prior to op1). - Cycle800 cancels in the correct place (after the second op). The problem comes in between these two operations. Look closely at the code that is output. I trimmed down the image from my first post to show area of focus... Here is the sequence of events... - Cycle800 is called and everything is rotated in preparation for machining - Operation #1 runs correctly, including the programmed retract to the Z11.480 clearance value at the end of operation - Operation #2 comment is posted - Tool offset is called (for no apparent reason, there has been no change, but this is no big deal) - The next three lines of code are the problem... - X.011815 (<-This is correct) Y-11.48 (<- This is incorrect. 11.48 is the current Z value) - Z-.568493 (<- This is incorrect. The Z is already in position, no call is necessary. Also, this is the correct value for the Y axis, not Z) - Y-.568493 Z10.375 (<- Here is where the post finally gathers its wits and spits out the correct values, which would of course be too late if you were to run this code.) - From here on, everything runs as it should/as is expected...

Thank you Colin. This is helpful information, but my problem is not with the retract moves within an operation, but rather in between two separate operations on the same tool plane. The post seems to be forgetting where it is at when transitioning between these two operations. I guess, chewing on this further, it is not actually forgetting where it is, but rather it is deactivating, and then reactivating, the TWP. When this occurs, even though no moves have been output, the XYZ coordinates have technically changed, which the post then interprets as requiring a position call. "Has your position changed?" "Well, I haven't moved, but I am technically in another location." ------------------ I trimmed down my mcam file and output a Z2G if anyone wants to take a peak... shrunk.ZIP

Interesting. I will have to look around at the other options out there in the future. It is hard to tell what is legit and what is garbage, perhaps going the "safe" route and purchasing from them was a mistake. I'll try to strip my file down and put together a Z2G when I get a second. The ptlchg$ logic is where I went first, perhaps I gave up on it too soon. An out of place p_deactivate_twp or its call criteria might explain the problem perfectly... Thank you for the help.

Let's back this up a bit... If you can't see how a halfway intelligent person would take exception to your initial response, I don't know what to tell you. ~"Did you call support? I've never had trouble. Pound sand."~ That is how it reads. Given your last post, I can see where it is coming from, but what do you expect? Clearly, given your explanation, you wrote that first response with the assumption that I was a xxxx, and it reads like it. I apologize for throwing it back at you, but I don't have a duck's back, what can I say? Let's start over... I am not a thief. I own my software and the posts that I use. I have contacted support, but it may be 24 hours, or 5 days until I get a solution. You never know, so I like to try and figure out my own problems in parallel when possible. Deadlines don't wait for tech support, so neither can I. If there is a chance I can fix it on my own, I dig in while I wait. I actually put a decent amount of thought into the snippets that I posted. I assumed neither CNC Software nor my reseller would like me posting too much of their IP on an open forum, so I chose to limit it to only what I saw as the pertinent areas. I am not asking anyone to do my work for me. I posted an example of my issue, what I tried as a solution, and the result I got, then asked if people saw any potential snags with my approach. Am I on the right path? Should I be looking elsewhere? Is this "fix" going to cause me grief when I call some other combination of toolpaths? That is all. Perhaps some more supporting information that would be helpful is missing? No problem, just ask. If anyone is still with me at this point, I am using the CNC Software Siemens 840D post, with the standard Table/Table_AC mmd thats comes with it, on a Hyundai XF6300 (it's an oddball machine, I know.) This same sequence of operations on any vertical 3 axis post for a vertical, or 3+1 axis post on a horizontal would not result in this behavior. Somehow, in between operations, the post is losing track of the toolplane it is on and throwing spurious movements...

I am happy for you and your decade of no problems. I apologize for defaulting to to snark, and I do appreciate you taking the time to reply, but your response is hardly helpful. I am working with my post supplier to resolve the issue, however, I will on occasion try to wipe my own butt when necessary. I too have been at this for some time (well over 2 decades if we are measuring D's), and I have more than once found better solutions than tech support was able to offer. Clearly, this is probably not going to be one of those times, but that doesn't mean you shouldn't be attempting to understand and work the problem. A better understanding of all the tools in your toolbox makes you a more valuable asset. Perhaps the post processor development forum is not the best place to seek input and advice on post processor development?

This is what I have managed so far in the way of correcting this behavior. By adding the highlighted lines to my post and forcing a cycle800 call, I am able to get rid of the erroneous movements in this case (as seen in the attached code). As a side effect of this "fix", I do get numerous extra cycle800 calls elsewhere in my program however. Plus, I am not sure if I am also going to end up with other unintended consequences... Any thoughts on what I have done here, how it could be improved, or perhaps better approaches to the issue?

I am flying right along with my 5axis toolpaths, but can't seem to figure out that complicated 3axis stuff. Confused? So am I. Here is a chunk of code I posted out. It consists of two simple toolpaths, a 2D contour, and a helix bore. Both toolpaths use the same WCS (top), CP, and TP (both front). For some reason the post seems to be losing track of where the TWP is at when it transitions from one op to the next, and is confusing the Y and Z axis. This is resulting in some unsafe movements. Take a look at the area I've highlighted. It moves to Z clear as intended, prints MSG, spits out the tool offset for no apparent reason, sends the Y axis out into nowhere, tries to drive the spindle into the table, then suddenly realizes it's error and moves to the correct location...