New Program Check Rule - Mismatched Data Types in Relational Contacts

[franji1]

As a developer, I have been burnt when comparing two different values that are actually 2 different data types (e.g. D0 > V0).  The range of values are different, or even their resolutions are different (e.g. integer vs. real, V0 = R0).

For example,
D0 > V0
a SIGNED 32 BIT INTEGER (D0) has a range of -2Billion to +2Billion, but an UNSIGNED 16 BIT INTEGER (V) has a range of 0..65535 (i.e. D's can go negative or get large, but V's can't).  Since the two elements' value ranges are not the same, the comparison result may not be what I expected.  For example, if D0 has a value of -1, the D0 > V0 comparison will ALWAYS be FALSE, regardless of any value of V (0-65535).

As a developer, I must ask myself some questions.  The first question, is this -1 value even possible for the D?  If not, everything is good.  If it CAN be negative, is the comparison result (FALSE) what I want?  OR, could it be I should have used a SIGNED INTEGER for the Right Hand Side (e.g. N0 or D1, but not V0)?  Or ? ? ?

There are other situations, like comparing a Timer Accumulator value (SIGNED 32 BIT INTEGER in MILLISECONDs) against a REAL constant that is in SECONDS, like
T0.Acc >= 3.5
This looks correct, thinking that the value units on both sides are SECONDs, but they are DIFFERENT (milliseconds vs. seconds).  This is can easily be misunderstood because the STATUS of T0.Acc is formatted in Hours/Minutes/Seconds.milliseconds, so T0.Acc (integer in milliseconds) appears to be in seconds when doing status.  This is definitely a situation where having a Program Check rule would have been helpful.

What say you?  Would it be a nuisance, or would it be helpful?  Feel free to answer the poll and/or comment!

As with ALL Program Check Warnings and Messages, you can IGNORE them judiciously at a rung, code-block, project, or global level (this new rule would be a MESSAGE BTW, not a warning).

[franji1]

Attached is an actual example of how this Program Check Rule would appear in Designer.

[Garyhlucas]

I'd say this could be a good idea as a problem like this could be VERY hard to diagnose when data is flying by. I would suspect the action would appear totally random making it even harder to diagnose.

[Bolt]

Well, I tried to vote NO, but it went in as NOT SURE. I had the tab open for hours though so that may have something to do with it.

So no, I don't think it's necessary, I tend to use my D/N/R/V memory accordingly. I do compare a V:D or V:R frequently, but it's not a problem for me. I know the messages are dismissable but seems like every new system or version update I spend a lot of time having to ignore them.

I think part of the frustration with having to ignore them is that it pops up when I'm ready to do a program write, I think I'll write it first then clear them. I think? that the Output pane closes after writing, so I either forget about it or have to run a Program Check which I have to find in the menus. So I usually end up closing the Write PLC dialog box, ignoring the messages, and then going back to Write PLC.

[franji1]

I think part of the frustration with having to ignore them is that it pops up when I'm ready to do a program write, I think I'll write it first then clear them. I think? that the Output pane closes after writing, so I either forget about it or have to run a Program Check which I have to find in the menus. So I usually end up closing the Write PLC dialog box, ignoring the messages, and then going back to Write PLC.

Program Check must be ran before any download to ensure the program has no "errors".  If you want to be nagged more preemptively, there's an option to run it after F8 Accept under Global Options (so you can deal with them as you go instead of at the critical point of writing to the PLC).

[brucek]

I selected other:
I guess my programs are all small enough that i compare V's to V's and D's to D's.

[franji1]

We added two new program check rules for 2.10 due out later this year.  Both rule levels will be Information/Message (not even a Warning; see first attached screen shot for examples of each).

• M133 Relational-Contact data types different between left & right side
• M134 Equality comparison between two 32-bit REAL values may not be accurate

Since the application of these new rules are sometimes nitpicky, both rules will initially be IGNORED at the PROJECT Scope Level.  So the rule violation will never show up until you modify the Program Check Rule Scope Level for those two rules (M133/M134).  To no longer ignore these new rules, go to the Tools->Ignored Program Check Rules and select the specific rules, then hit the [Unignore Rule] button (see the second attached screen shot).  Once they are unignored, you will see them being reported by Program Check mechanism, like in the first example.

(Note: any Information/Message or Warning Program Check violation can be ignored at the Rung, Code Block, Project, or Global level just by right clicking on the rule in the Output Window after running Program Check).