Nixter (Customer) asked a question.

August 20, 2026 at 11:44 PM
Compare Instruction Does Not Work Properly

How is this possible? (see screen grab):

imageWhen I place a number instead of the tag on the RHS of the compare instruction, it works as expected.

 

The tag on the RHS is assigned to by a Math instruction a few rungs above the compare instruction. It is not assigned anything anywhere else. There are rungs that reference the tag on the RHS of the compare instruction, but they are all compare instructions, so they will not influence the contents of that tag. Very strange!

 

  • 10 answers
  • 124 views

  • bcarlton (Customer)

    Verify the left hand value at this rung execution time by copying its value to an unused float tag in a rung immediately before this one. Be sure the output bit is not used anywhere else.

    Selected as Best

  • Nixter (Customer)

    I should have included the following context: The PLC is a P3-550E and the Productivity Suite programming software that I am using is 4.7.1(5)

     

    The screen grab was from a running PLC. It's not a simulation. Also, the rung is in a task that is a "Run every scan" type.

     

    • Nixter (Customer)

      Well, I tried substituting a floating point number in for the tag and it did work properly the last time I tried, but when I tried again...

       

      imageHere's the compare instruction when I double-click on it:

       

      imageVery strange and worrisome as this PLC is controlling equipment and it appears I can't depend on it to get such a simple instruction right!!!

       

      Automation Direct... you've got me worried!

       

      I'm hoping you can show me something I'm doing wrong...

      Expand Post

  • bcarlton (Customer)

    Verify the left hand value at this rung execution time by copying its value to an unused float tag in a rung immediately before this one. Be sure the output bit is not used anywhere else.

    Selected as Best

    • Nixter (Customer)

      The BOOL output bit Programmers_Test_OUT_01 was created specifically for the test rung.

      I did a cross-reference on it and (unsurprisingly) the test rung is the only place it is found.

       

      The big surprise was when I saw the result of the rung you asked me to create, where I copied the value on the LHS of the compare HMI_COL2_Reboiler_Level_Inches to a new otherwise unused float tag (created for just this test). The value that was copied to the new float tag was very different from the one I saw in the HMI_COL2_Reboiler_Level_Inches tag!

       

      Clearly, there is a bug in my code as the tag on the LHS of the compare is being assigned a value in more than one place in my program and the value I am seeing displayed in Monitor-Mode is NOT the actual value of the tag when the compare executes.

       

      Thank you!

      Expand Post

      • kewakl (Customer)

        Clearly, there is a bug in my code as the tag on the LHS of the compare is being assigned a value in more than one place in my program and the value I am seeing displayed in Monitor-Mode is NOT the actual value of the tag when the compare executes.

         

        It may not be a bug in your code.

        I think that Bernie was guiding you to see the tag values were as expected when THAT rung was evaluated, but were updated later.

        The software's updating of what is displayed on the screen may not reflect the value of the logic that you are currently viewing.

         

        The 'Last One Wins' principle exists here, too..

         

        Expand Post

      • Nixter (Customer)

        Yes, it got me thinking about exactly what you described.

         

        With BOOL tags, I almost never assign more than 1 output instruction to a BOOL tag, except the in the case of SET / RESET pairs. With ints and floats, the situation is different in that I often use logic that assigns an "impossible" value to a tag and then have additional logic that assigns values to that tag that depends on the process or machine state at the time of logic execution. A check for the "impossible" value (eg. -999) is used to indicate that some error (or unanticipated) process or machine state occurred and there is logic to handle that condition (so, it's handled gracefully). I take great pains to ensure that after the initial assignment of an "impossible" value, there is logic to ensure that the float or int tag in question is only assigned a value in just one place and not in mulitple places in the code. That makes the code more reliable and easier to follow and debug. I will check through my program today to see if I have inadvertently created code that makes more than one assignment to the float tag that is causing the issue with the CMP instruction.

         

        What complicates my current situation is that I'm working over a VPN and there is a significant amount lag associated with screen updates. So, what the PLC is seeing as the value of the tag can be quite different from what I am seeing on my screen.

         

        Thanks for your input. Much appreciated.

        Expand Post

  • bcarlton (Customer)

    That bit me more than once in my career (those occurrences being the source of most of our 'wisdom' on these forums). In most PLCs the communications with a programming device or hmi occur between scans, thus the value sent is what exists at that point.

    • Nixter (Customer)

      I agree and thank you very much for your help. It is greatly appreciated.

  • ADC Community_02 (Automationdirect.com)

    @Nixter (Customer)​ If needed you can PM me your project I can attempt to duplicate the issue. Just let me know the task and rung location of the offending tag or instruction.

    • Nixter (Customer)

      I won't bother you with this. The test that bcarlton (Customer) suggested showed me that it's an issue in my program and I know how to fix it. The CMP is doing exactly what it's supposed to.

       

      Thank you for the offer though!

 

Did this information resolve your issue?