Studio 5000 integer to Real with 0 digit replacement

[drbitboy]

Either that, or

• MOD Error_index 100 Advanced_error_code
  • Result of [Error Index] MODulo 100 => [Advanced Error Code}
• SUB Error_index Advanced_error_code Error_code
  • Subtract [Advanced Error Code] from [Error Index], save result, which will end in 00
• DIV Error_code 100 Error_code
  • Divide that result by 100 => [Error Code]
• Have 3 HMI widgets:
  • Left-most widget displays numeric [Error Code], right justified
  • Middle widget displays a decimal point
    Right-most widget displays numeric [Advanced Error Code], left justified.

 

[jbradtke9112]

So after some testing, I had to keep the final result as a String instead of a Real because Rockwell deletes all trailing zeros for Reals. Because the error code list has both 1.1 and 1.10 and corresponds to different remedies they required me to keep the result error code as a string. Sucks but it is what it is.

Here's a screenshot of the final code and some of the resulting message strings. The last screenshot is the 10.xx condition which checks the location of the decimal and then adds the code into the final output message test (as this value can change according to the manual)

Thanks all!

Edit: I just saw the previous 3 replies so I guess it just took me some testing to get to the same conclusion. I understand what everyone is saying with storing the Error code separately from the advanced error code but I don't have a reason to keep them separate as I have a lookup table for each unique error code. Looks like they grouped the error code by 1 (output Fault) 2 (input fault) 3 EDM(External Device monitoring Fault) 4 (Device Fault).....etc. I don't have a use for the grouped code so for me I'll keep the error code as a combined.

 

[IO_Rack]

So after some testing, I had to keep the final result as a String instead of a Real because Rockwell deletes all trailing zeros for Reals.

I believe this would be true for pretty much all PLC programming software. In fact, if the value somehow got very small or very large it would show in scientific notation. How it's displayed in the PLC monitoring shouldn't matter.

I'm assuming you want the user to view this information somewhere. In most HMIs, you can format a numeric display to show a fixed leading and/or trailing decimal places.

 

[drbitboy]

Because the error code list has both 1.1 and 1.10 and corresponds to different remedies they required me to keep the result error code as a string. Sucks but it is what it is..

[I know you have it working, so this is just food for thought.]


That being the case, and since you are manually search for the known matching string (1.1, 1.10, 10.xx, etc) and using that to load string into the value of Out_Fault_Msg_Text anyway, why not search for the known matching Error Index i.e. for the 16-bit integer (101, 111, 102, etc.)?

In fact, you could load up all the possibilities into parallel Error_Indices integer, and Out_Fault_Texts string arrays (or an array of UDTs with [error index, fault text] pairs), and use the FSC command to locate the index into those arrays that matches the original 16-bit error code.

That way the whole implementation is but two instructions, plus a one-time manual creation of the arrays (which you have already done in the **EQU Flt_Code_String "1.1" MOV "Fault Code 1.1 ..." Out_Fault_Msg_Text** rungs anyway. It also leaves open the possibility of being able to handle additional error codes in the future, e.g. if the hardware is updated, or updating the error message text in the data without changing the code.

 

[IO_Rack]

Because the error code list has both 1.1 and 1.10 and corresponds to different remedies they required me to keep the result error code as a string.

Oops... I missed that part. Obviously formatting the REAL would make no difference.