prv_cabs <> cabs

[SlaveCam]

I keep seeing this line in posts that checks if there is C-axis motion to be done. I have found that this is not a reliable comparison in most cases (floating point comparisons are tricky). I've come across situations where the abovementioned line has evaluated to false even if both have been seemingly integer numbers.

Is there some rule-of-thumb on where prv_cabs <> cabs can be deemed reliable, and when fmtrnd(prv_cabs) <> fmtrnd(cabs) should be used instead?

[Colin Gilchrist]

11 minutes ago, SlaveCam said:

I keep seeing this line in posts that checks if there is C-axis motion to be done. I have found that this is not a reliable comparison in most cases (floating point comparisons are tricky). I've come across situations where the abovementioned line has evaluated to false even if both have been seemingly integer numbers.

Is there some rule-of-thumb on where prv_cabs <> cabs can be deemed reliable, and when fmtrnd(prv_cabs) <> fmtrnd(cabs) should be used instead?

It really depends on which Post you are referring to.

In general, the variable 'c$' is used in the 4-Axis Posts, for any "single Rotation Axis". That would be the "internal variable", which gets used in calculations. The "output variables" are typically 'cabs' and 'cinc', depending on if the motion is Absolute or Incremental. In addition, there are different 'incremental variable functions'. For many years, there were only the 'abs' and 'inc' variables, and the incremental output was calculated from "current - previous".

Whenever a variable is output, is is always rounded to the "Format Statement, assigned by the Format Assignment", in the Post.

Since 'cabs' is an output variable; 'prv_cabs' will always contain "rounded output", according to the Format Assignment.

I would recommend using 'if prv_cabs <> fmtrnd(cabs)', which should always be comparing "like to like". (rounded values)

      if use_rot_lock & rot_on_x,
        [
        if (index = one & (prv_indx_out <> fmtrnd(indx_out)) | (prv_cabs <> fmtrnd(cabs)))
           | nextop$ = 1003
           | frc_cinit, prot_unlock
        ]

The code above is from MPFAN.

I added "carriage returns" after each "OR" condition (|), which breaks each condition onto a separate line. This is legal to make it easier to read the logic.

Notice that we've got >

IF index = one

AND 

(prv_indx_out <> fmtrnd(indx_out))  OR (prv_cabs <> fmtrnd(cabs))

So the first condition is linked with an 'and'. Meaning, the 'index' variable must be equal to 1, and previous index out, is not equal to, the 'rounded value' of index out, OR previous 'rotary abs value', is not equal to, the 'rounded value' of rotary axis absolute.

Not sure if it matters to you; but it is good to know that the 'fmtrnd' function, does not actually "round the current value of the 'cabs' variable". Technically, the MP.DLL engine creates a 'copied value of the variable when 'fmtrnd' is utilized'. So in the background, MP is creating a unique variable, "indexed to that line and column" in the Post, which is used to temporarily hold the rounded value of 'the target variable'.

Technically, due to the processing power of today's computers, we don't really have to worry about the performance hit the incurs.

But take the following example:

pretract        #End of tool path, toolchange
      sav_absinc = absinc$
      absinc$ = one
      pcool_off
      if prv_cabs <> fmtrnd(cabs), "do 1st thing", e$
      #cc_pos is reset in the toolchange here
      cc_pos$ = zero
      gcode$ = zero
      if prv_cabs <> fmtrnd(cabs), "do 2nd thing", e$
      if use_rot_lock & rot_on_x,
        [
        #condition below is '3rd use of 'prv_cabs <> fmtrnd(cabs)'
        if (index = one & (prv_indx_out <> fmtrnd(indx_out)) | (prv_cabs <> fmtrnd(cabs)))
          | nextop$ = 1003 | frc_cinit, prot_unlock
        ]
      pbld, n$, sccomp, *sm05, psub_end_mny, e$
      if convert_rpd$, pconvert_rpd
      if prv_cabs <> fmtrnd(cabs), "do 4th thing", e$
      pbld, n$, [if gcode$, sgfeed], sgabsinc, sgcode, *sg28ref, "Z0.", [if gcode$, feed], scoolant, e$
      if nextop$ = 1003 | tlchg_home, pbld, n$, *sg28ref, "X0.", "Y0.", protretinc, e$
      else, pbld, n$, protretinc, e$
      absinc$ = sav_absinc
      coolant$ = sav_coolant
      uninhibit_probe$

In that above example, due to the "positioning within the Post Block", where we want to test 'prv vs. current' cabs, we actually have 4 different 'temporary variables' that are used, as a result of using 'fmtrnd', with the same conditions.