Wierd unwind output

[So not a Guru]

We have a head/head router. When they are generated, to get rid of "C" unwinds on 5X paths, we set our mi9$ (nutating bias, default is "2") to 0 & set our mi4$ (initial primary C, default is "0") to a value that will, essentially, prewind "C" so that the unwind is not needed.

This works fine, except occasionally when there is a "pocket", "2D contour (ramp)" or "circle mill (helix)" toolpath operation before the 5X path (not necessarily directly preceding, anywhere prior to the 5X path), in the same ncfile group.

When that happens, the ncfile generates the unwind, as if the mi values are at their default values.

I'm not very good at using the debugger tool, so I'm having a hard time fnding where the values are being reset at. Does anyone have an idea where I might start looking?

[Colin Gilchrist]

You probably have an issue with the Bias Settings. These are 'mi4$' and 'mi5$'. They are only applied, by default, at the tool change event.

Look in your post for 'bias_null'. Turn this on so that 'mi4$' is applied at a Null Tool Change.

[So not a Guru]

8 minutes ago, Colin Gilchrist said:

You probably have an issue with the Bias Settings. These are 'mi4$' and 'mi5$'. They are only applied, by default, at the tool change event.

Look in your post for 'bias_null'. Turn this on so that 'mi4$' is applied at a Null Tool Change.

I had already tried that, it made no difference.

Really an odd one, it only gets wonky when 2D paths that make simultaneous xyz moves are ahead of the 5x operation.

[So not a Guru]

Ok, I was able to correct the issue. the post has a rotary reset postblock:

protretinc      #Reset the C axis revolution counter
      if frc_cinit,
        [
        p_abs = zero
        p_inc = zero
        s_abs = zero
        s_inc = zero
        pset_dlt_to_abs
        p_wnd_ang = zero
        s_wnd_ang = zero
        !p_wnd_ang, !s_wnd_ang
        ]

This was being called in my pretract postblock. Since at forced tool changes, the "C" & "A" axes are already being reset, deleting the call is not a problem.

Now I've just got to create some logic that will reset the rotary axes when forced tool change is off.

Thanks again guys for the help.

[crazy^millman]

1 hour ago, So not a Guru said:

Ok, I was able to correct the issue. the post has a rotary reset postblock:

protretinc      #Reset the C axis revolution counter
      if frc_cinit,
        [
        p_abs = zero
        p_inc = zero
        s_abs = zero
        s_inc = zero
        pset_dlt_to_abs
        p_wnd_ang = zero
        s_wnd_ang = zero
        !p_wnd_ang, !s_wnd_ang
        ]

This was being called in my pretract postblock. Since at forced tool changes, the "C" & "A" axes are already being reset, deleting the call is not a problem.

Now I've just got to create some logic that will reset the rotary axes when forced tool change is off.

Thanks again guys for the help.

I will normally comment out something in the post I think I don't need verse deleting it. Put a note and date to it and then if I ever do need it again I can just uncomment. By deleting it you are not giving yourself enough information to correct it down the road if you need to.

BTW good work sorting all this stuff out.

[So not a Guru]

1 hour ago, 5th Axis CGI said:

I will normally comment out something in the post I think I don't need verse deleting it. Put a note and date to it and then if I ever do need it again I can just uncomment. By deleting it you are not giving yourself enough information to correct it down the road if you need to.

BTW good work sorting all this stuff out.

That's what i do, and did here, Ron. I should have been more precise in my explanation.

Thanks, you guys on this forum have been such a fantastic resource and y'alls patience with me is much appreciated.

[crazy^millman]

2 minutes ago, So not a Guru said:

That's what i do, and did here, Ron. I should have been more precise in my explanation.

Thanks, you guys on this forum have been such a fantastic resource and y'alls patience with me is much appreciated.

All good just for those that read these threads and don't read between the lines.

Someone has been patience with us least we can do is return the favor.

[Colin Gilchrist]

With that particular block, there is a Switch that controls entry into the brackets.

"frc_cinit" this stands for "force 'c' initialize", and when the variable is "enabled", or turned on, will the code below execute. Simply setting 'frc_cinit' to '0' will skip all that logic. No need to comment it out. Just turn it off if you don't need the output. I prefer that to commenting it out.

[crazy^millman]

5 minutes ago, Colin Gilchrist said:

With that particular block, there is a Switch that controls entry into the brackets.

"frc_cinit" this stands for "force 'c' initialize", and when the variable is "enabled", or turned on, will the code below execute. Simply setting 'frc_cinit' to '0' will skip all that logic. No need to comment it out. Just turn it off if you don't need the output. I prefer that to commenting it out.

Colin couldn't you go a step further and use a mi or mr trigger to then control the behavior?

[So not a Guru]

7 hours ago, Colin Gilchrist said:

With that particular block, there is a Switch that controls entry into the brackets.

"frc_cinit" this stands for "force 'c' initialize", and when the variable is "enabled", or turned on, will the code below execute. Simply setting 'frc_cinit' to '0' will skip all that logic. No need to comment it out. Just turn it off if you don't need the output. I prefer that to commenting it out.

That is actually what I originally did, but I still got the output. I commented out the call in the pretract postblock & it ended the behavior. This is a very screwy post. I haven't yet been able to make it generate arcs!

[Colin Gilchrist]

On 3/23/2017 at 0:19 PM, 5th Axis CGI said:

Colin couldn't you go a step further and use a mi or mr trigger to then control the behavior?

Absolutely.