Jump to content

Welcome to eMastercam

Register now to participate in the forums, access the download area, buy Mastercam training materials, post processors and more. This message will be removed once you have signed in.

Use your display name or email address to sign in:

SIEMENS 840D, TWP'S, AND CLEARANCE MOVES


DROB
 Share

Recommended Posts

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

 

2.png

Link to comment
Share on other sites

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? 

3.png

1.png

Link to comment
Share on other sites

When you reached out to the post supplier with a sample file what was their response? I have programmed CYCLE800 and TRAORI for well over a decade and never had problems, but I also work with the post builders and my reseller to communicate issues I am running into. If you aren't and trying to wing it on your own then best of luck.

  • Like 1
Link to comment
Share on other sites
20 hours ago, crazy^millman said:

When you reached out to the post supplier with a sample file what was their response? I have programmed CYCLE800 and TRAORI for well over a decade and never had problems, but I also work with the post builders and my reseller to communicate issues I am running into. If you aren't and trying to wing it on your own then best of luck.

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?

  • Like 1
Link to comment
Share on other sites
2 hours ago, DROB said:

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?

Well the problem is you didn't provide a full break down of the post or a sample file just some snip of something and someone is suppose to read your mind and take your 20 years of experience and figure it out for you. Yes asking for help in the post area is the correct place, but like so many arrogant people who come here asking for help you didn't provide a post or a sample to help you. Glad to help anyone when I have what I need to help them, but a snip of a section of a post and no back story you are working with the post supplier then it comes off like many over the last 18 years on this forum of people who are not legally using the software trying to cheat the system. I earn a living supporting and helping paying customers and Mastercam is purchased and owed by my company the one I own. As a direct partner to CNC Software/Sandvik I understand when people don't provide enough information, but then expect someone to read minds and figure something out without providing everything needed to help figure it out and then get all pissy because someone wants to get an idea are you a legal user of the software or not. I got nothing to hide, but your 2nd posting is a extremely in depth and complex process breaking down CYCLE800 and TRAORI processes that with the correct post should be doing what you need, but again no post to review just some snips of code and we are suppose to piece it all together and be mind readers. What kind of Machine wasn't supplied. What kind of kinematics the machine has was not supplied. The builder of the machine was not supplied.

Again information that is helpful to get a feel for what your running into. Then start to whole thread it we got this snarkyness.

Quote

but can't seem to figure out that complicated 3axis stuff. Confused? So am I.

No I am not confused and not had any issues doing 3 Axis stuff with Siemens controls on 20 different machines over the last decade. I have no sample file you provided or enough details to help. I tried to pry some information out of you to start a dialog and wished you the best of luck, but I am the mean one in the conversation? I have also found many times other solutions for help than Tech Support offers, but when you call tech support for any company they ask you some basic questions to get details. Good ones will try to do a screen share and see what the person they are trying to help is also seeing. One other thing from most tech support companies is they verify some information from the person calling to make sure the person is a legitimate customer. Mazak is not helping Okuma customers or HAAS customers. I can't not go to a NX forum asking help for Mastercam questions. Problem is Mastercam is one of the most pirated softwares for Manufacturing in the world. When something quacks like duck, walks a like a duck and talks like a duck then someone trying to gather information might think they are duck. When someone comes in and provides details and good information like company name and contact information, Sample file or Z2G so someone can verify details then they are thinking okay legit user needing some help on a what they consider complex issues that isn't one.

Other than that seeing how I was the only one that even chimed in you might back up provide some good information then you will this head in a different direction. If not then apologize I was unable to read your mind and get it figured out with enough good information to do so.

Link to comment
Share on other sites
19 hours ago, crazy^millman said:

Well the problem is you didn't provide a full break down of the post or a sample file just some snip of something and someone is suppose to read your mind and take your 20 years of experience and figure it out for you. Yes asking for help in the post area is the correct place, but like so many arrogant people who come here asking for help you didn't provide a post or a sample to help you. Glad to help anyone when I have what I need to help them, but a snip of a section of a post and no back story you are working with the post supplier then it comes off like many over the last 18 years on this forum of people who are not legally using the software trying to cheat the system. I earn a living supporting and helping paying customers and Mastercam is purchased and owed by my company the one I own. As a direct partner to CNC Software/Sandvik I understand when people don't provide enough information, but then expect someone to read minds and figure something out without providing everything needed to help figure it out and then get all pissy because someone wants to get an idea are you a legal user of the software or not. I got nothing to hide, but your 2nd posting is a extremely in depth and complex process breaking down CYCLE800 and TRAORI processes that with the correct post should be doing what you need, but again no post to review just some snips of code and we are suppose to piece it all together and be mind readers. What kind of Machine wasn't supplied. What kind of kinematics the machine has was not supplied. The builder of the machine was not supplied.

Again information that is helpful to get a feel for what your running into. Then start to whole thread it we got this snarkyness.

No I am not confused and not had any issues doing 3 Axis stuff with Siemens controls on 20 different machines over the last decade. I have no sample file you provided or enough details to help. I tried to pry some information out of you to start a dialog and wished you the best of luck, but I am the mean one in the conversation? I have also found many times other solutions for help than Tech Support offers, but when you call tech support for any company they ask you some basic questions to get details. Good ones will try to do a screen share and see what the person they are trying to help is also seeing. One other thing from most tech support companies is they verify some information from the person calling to make sure the person is a legitimate customer. Mazak is not helping Okuma customers or HAAS customers. I can't not go to a NX forum asking help for Mastercam questions. Problem is Mastercam is one of the most pirated softwares for Manufacturing in the world. When something quacks like duck, walks a like a duck and talks like a duck then someone trying to gather information might think they are duck. When someone comes in and provides details and good information like company name and contact information, Sample file or Z2G so someone can verify details then they are thinking okay legit user needing some help on a what they consider complex issues that isn't one.

Other than that seeing how I was the only one that even chimed in you might back up provide some good information then you will this head in a different direction. If not then apologize I was unable to read your mind and get it figured out with enough good information to do so.

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

Link to comment
Share on other sites
1 hour ago, DROB said:

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

All good here and glad we can have a conversation. 😀

Got everyone fooled on the intelligence front. 😉

Since you are using the CNC software Siemens 840D post then making a sample Z2G will be no problem.

I suspect you are correct about losing the plane and you did correct in the logic you added. I normally used 3rd Party Post people why I haven't run into this. Sorry, but the Generic Post out of CNC Software are not as the same level as 3rd Party and haven't been for sometime why I use 3rd Party for all 5 Axis and Mill/Turn Posts when I can. 

A quick test you do do in force a tool change in between the 3 axis and 5 axis operation or in between planes and see if the post if giving you run able code. If it is then the reset logic for null tool change is the issue and will need to work on getting that sorted out. Since you have a CNC software post and not a purchased post expect for a slower response than if it were a purchased post.

Link to comment
Share on other sites
32 minutes ago, crazy^millman said:

All good here and glad we can have a conversation. 😀

Got everyone fooled on the intelligence front. 😉

Since you are using the CNC software Siemens 840D post then making a sample Z2G will be no problem.

I suspect you are correct about losing the plane and you did correct in the logic you added. I normally used 3rd Party Post people why I haven't run into this. Sorry, but the Generic Post out of CNC Software are not as the same level as 3rd Party and haven't been for sometime why I use 3rd Party for all 5 Axis and Mill/Turn Posts when I can. 

A quick test you do do in force a tool change in between the 3 axis and 5 axis operation or in between planes and see if the post if giving you run able code. If it is then the reset logic for null tool change is the issue and will need to work on getting that sorted out. Since you have a CNC software post and not a purchased post expect for a slower response than if it were a purchased post.

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.

Link to comment
Share on other sites

DROB,

You're on the right track, with adding logic to test for conditions like "is this a new operation" (NCI 1000). However, it is important to know that "Depth Cuts" and "Multi-passes" each output a Null-Tool Change block to the NCI File. I suspect that is why you'd be getting the extra TWP calls, between cuts. I think you'd need to modify the logic to detect "has the op_id$ really changed, or is this really still the same operation, but a new cut?")

Most CNC Software derived 5-Axis Posts, started life as a "completely vector based, old-school approach" for repositioning between cuts. In other words; the original 5-Axis Post was designed to calculate "safe" approach and retract moves, based on the kinematic setup of the machine (defined by variables in the Post itself), and based on the "Misc. Integer and Real Number values", which are passed on each operation.

Take this with a grain of salt, as it may only describe "historical behavior" of the Post, and may not actually apply to your specific version!

At the Operation Level, we've got 1-10 Integers, and 1-10 Decimal Numbers, that are available to the Post Developer, to "trigger" output from the Post Processor.

One of the features of the original Generic Fanuc 5X Mill Post, is the "Vector approach and retract", typically done with MR1.

If you look at Miscellaneous Real Number 1 (mr1$ variable), this is typically used for the Approach and Retract vectors.

There is a function inside the old Generic Fanuc 5X Mill Post, which lets you define a "box" to use for Approaching and Retracting from the part. This can be "a linear offset from the User Defined Stock", or it can be hard-coded positions in the Post Processor.

The purpose is to allow you to program 3+2 cuts, using different Tool Planes (think, cutting on Front, then immediately cutting on Back), and the Post will take care of all the "intermediate position vectors", to both move the tool "around the boundary", but also to reposition your rotaries.

Depending on how the logic gets called, and the Operations in your Mastercam File are Programmed, the MI/MR values can be used to tweak the Post output, and also to perform the vector approach/retract moves for repositioning between different Toolplanes. Note: the Vector App/Ret logic basically works between any operation, so you can apply this to 5X App/Ret moves "between operations" as well.

But again, this also depends on the particular Post you are using, and what particular Post Blocks are getting called.

 

Link to comment
Share on other sites
On 10/22/2021 at 1:41 PM, Colin Gilchrist said:

DROB,

You're on the right track, with adding logic to test for conditions like "is this a new operation" (NCI 1000). However, it is important to know that "Depth Cuts" and "Multi-passes" each output a Null-Tool Change block to the NCI File. I suspect that is why you'd be getting the extra TWP calls, between cuts. I think you'd need to modify the logic to detect "has the op_id$ really changed, or is this really still the same operation, but a new cut?")

Most CNC Software derived 5-Axis Posts, started life as a "completely vector based, old-school approach" for repositioning between cuts. In other words; the original 5-Axis Post was designed to calculate "safe" approach and retract moves, based on the kinematic setup of the machine (defined by variables in the Post itself), and based on the "Misc. Integer and Real Number values", which are passed on each operation.

Take this with a grain of salt, as it may only describe "historical behavior" of the Post, and may not actually apply to your specific version!

At the Operation Level, we've got 1-10 Integers, and 1-10 Decimal Numbers, that are available to the Post Developer, to "trigger" output from the Post Processor.

One of the features of the original Generic Fanuc 5X Mill Post, is the "Vector approach and retract", typically done with MR1.

If you look at Miscellaneous Real Number 1 (mr1$ variable), this is typically used for the Approach and Retract vectors.

There is a function inside the old Generic Fanuc 5X Mill Post, which lets you define a "box" to use for Approaching and Retracting from the part. This can be "a linear offset from the User Defined Stock", or it can be hard-coded positions in the Post Processor.

The purpose is to allow you to program 3+2 cuts, using different Tool Planes (think, cutting on Front, then immediately cutting on Back), and the Post will take care of all the "intermediate position vectors", to both move the tool "around the boundary", but also to reposition your rotaries.

Depending on how the logic gets called, and the Operations in your Mastercam File are Programmed, the MI/MR values can be used to tweak the Post output, and also to perform the vector approach/retract moves for repositioning between different Toolplanes. Note: the Vector App/Ret logic basically works between any operation, so you can apply this to 5X App/Ret moves "between operations" as well.

But again, this also depends on the particular Post you are using, and what particular Post Blocks are getting called.

 

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

Link to comment
Share on other sites
2 hours ago, DROB said:

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

I looked at it and on 2 operations you have mi1 as Zero, but then on OP3 you have it was 1. According to the post in this section you will get different behavior.

# Misc. Integers:
#
#   mi1 -  CYCLE800 Retract Method
#          0 = No Retract
#          1 = Retract Z
#          2 = Retract Z, then XY
#          4 = Retract MAX along tool vector
#          5 = Retract incremental distance along tool vector.  See mr1.

This is a new flavor or post out of CNC Software and it will take some time to look through it and see what could be creating the issue were were describing.  I see the CYCLE800() for cancel working and the CYCLE800(,,,,,,,,,,,,,) for calling DWO working as I think it should.

Pay very close attention to the difference between each DWO call they are different which is important and looks correct. One is a 45 degrees and one is a 90 degrees. You have different rotations going on and CYCLE800 for each position must be called. Just search through the code using CYCLE800 as the search and you will see this flip flop back and forth through out the code. You have programmed a 45 degrees and then 90 degree move and the post is giving you what your want because of the way you programmed it. Where the planes are the same you are not getting redundant CYCLE800 calls, but where the plane changes you are.

CYCLE800(0,"XF6300",200000,57,0,0,0,45,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,90,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,45,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,90,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,45,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,90,0,0,0,0,0,1,0,0)

Please explain why you think you shouldn't be getting this output since everything I understand and know about CYCLE800 looks correct and should be doing what you are seeing.

Link to comment
Share on other sites
1 hour ago, crazy^millman said:

I looked at it and on 2 operations you have mi1 as Zero, but then on OP3 you have it was 1. According to the post in this section you will get different behavior.


# Misc. Integers:
#
#   mi1 -  CYCLE800 Retract Method
#          0 = No Retract
#          1 = Retract Z
#          2 = Retract Z, then XY
#          4 = Retract MAX along tool vector
#          5 = Retract incremental distance along tool vector.  See mr1.

This is a new flavor or post out of CNC Software and it will take some time to look through it and see what could be creating the issue were were describing.  I see the CYCLE800() for cancel working and the CYCLE800(,,,,,,,,,,,,,) for calling DWO working as I think it should.

Pay very close attention to the difference between each DWO call they are different which is important and looks correct. One is a 45 degrees and one is a 90 degrees. You have different rotations going on and CYCLE800 for each position must be called. Just search through the code using CYCLE800 as the search and you will see this flip flop back and forth through out the code. You have programmed a 45 degrees and then 90 degree move and the post is giving you what your want because of the way you programmed it. Where the planes are the same you are not getting redundant CYCLE800 calls, but where the plane changes you are.


CYCLE800(0,"XF6300",200000,57,0,0,0,45,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,90,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,45,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,90,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,45,0,0,0,0,0,1,0,0)

CYCLE800(0,"XF6300",200000,57,0,0,0,90,0,0,0,0,0,1,0,0)

Please explain why you think you shouldn't be getting this output since everything I understand and know about CYCLE800 looks correct and should be doing what you are seeing.

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

4.png

Link to comment
Share on other sites
3 minutes ago, DROB said:

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

4.png

Well that is something completely different and needs to go back to the reseller so they can get it addressed. The mapping between the operations is not outputting correctly and they need to look into that section. This is what I like to have a file and information to see specifics and sorry I can't be of more assistance with this one.

Link to comment
Share on other sites
25 minutes ago, crazy^millman said:

Well that is something completely different and needs to go back to the reseller so they can get it addressed. The mapping between the operations is not outputting correctly and they need to look into that section. This is what I like to have a file and information to see specifics and sorry I can't be of more assistance with this one.

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

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.

Join us!

eMastercam - your online source for all things Mastercam.

Together, we are the strongest Mastercam community on the web with over 56,000 members, and our online store offers a wide selection of training materials for all applications and skill levels.

Follow us

×
×
  • Create New...