Studio 5000 UTF-8

[Subsea7]

Hi all. I want to ask what may seem a stupid question, as I have a project to send live data to a Yeacode line printer which will print meterage stamps on an extruded product. The PLC is a 5580.

The string the printer needs to be sent is a text string and that part is looking fine due to getting used to sending tcp/ip data over ethernet using MSG instructions. The issue is that the string needs to be preceded by some hex values and the string must be sent in UTF-8 encoding. I've scoured the Rockwell documentation and can't see any mention of setting encoding for strings.

Maybe I can do it when creating a UDT string type of my own, haven't tried that but it occurred to me over the weekend that may be the answer.

So what may be obvious to others, I wonder if anyone can share how to send values such as 0xEB 0x00 etc as part of the string due to them potentially being "unprintable" ones?

 

[drbitboy]

Does this help?

 

[Subsea7]

Does this help?

Fantastic, that's all I needed. Thanks

 

[Subsea7]

So here's an aside to this, I cannot find an answer to, there may not be one. Here goes:

I build a text message string, with the data to send to the printer - all good. I then have to append that to a string of Hex bytes which tell the printer, I want you to print, left to right, it;s a dynamic message, and it's length is xx - followed by the text message itself. So like this '$EB$01$00$04$00$00$00$xx'<My Text To Print Etc>

Therein lies the issue. I create the Hex string, then on the end I have to get the length of the text message it needs to print, then that needs to be the last byte on the Hex string. Preceded of course by a $ character to make it into an ASCII Hex byte value to be sent.

Now, I cannot know the message length before hand, as it changes as the numbers sent to the printer change - so the message length changes, so that byte must be changed. Therefore it cannot be hard coded into the config string of bytes, but generated on the fly...yet I cannot for example get the hex value of say 85 and append that to $ as it is not allowed ($ being a special char). I tried making a value in a string of $24 (the '$' char code) then appending the 85 to it, and it creates a string of '$$85' (no use of course - and weird)

Then tried creating a string of $00 and appending the 85 to it (or what ever hex byte value the message length actually is at the time) then tried to MID the 00 out of the string '$0085' to get '$85' but it will not accept this, or at least no error results but the string remains unchanged.

How the heck can I take a value which is not previously known but calculated, then add a $ to the start of it? Anyone think of a way?

 

[drbitboy]

can you serialize that prefix string with a $00 as the last character? That would write to a SINT array, IIRC. Then you could change the last element of the SINT array to the length of the text message string (messy if its length is over 127 but doable). Finally deserialize the SINT array back to a string.

I forget what the serialize/deserialize instructions are called, but I have used them; I assume they would work with strings but I have not tried that. obviously if the string length is part of the serialization then you will need to allot room in the SINT array for that, but since that prefix string length is not changing, it might work okay.

 

[drbitboy]

Better option: see the SINT_TO_CHAR instruction.

 

[drbitboy]

Whoops! Somehow this became a siements project in the vacant lot of my head.

When you have a string, say the tag name is S, in studio 5k, it is actually a "structure" with two attributes: S.LEN and S.DATA. S.DATA is an array of SINTS, so you could simply write the suffix string's length via MOV suffix_length S.DATA[7],

 

[drbitboy]

see here

 

[MikeyN]

This is tricky!!! When you look at what you have, $85 is only one character. The same goes for $$ and $24 (the same thing). When you add 85 to $$ you end up with three characters. This is similar to sending an escape character, and then the data that follows. This is why you aren't getting what you need.

But I think I found the answer. If you check out the actual data for $85, $86, etc, you will see that they are simply BCD. Why not take the length of the string, and then use TOD to convert it to BCD with the end of your string as the destination. This should provide the hex code you need. See my very rudimentary example below.

 

[Subsea7]

Thank you so much guys, this is an excellent response and I will use these methods - and see how I get on.

A wee bit of further info, the length of the string is of course in Decimal, then I use a Dec to Hex routine to convert the value to a hex string, let's say 85 or 9B etc, so that probably wouldn't work as-is but with a bit of tweaking, should get me there. I will post back on results. Thanks to both for excellent replies.

 

[Subsea7]

So an update, it all "seems" to work as per the routine suggested by @MikeyN (similar to @drbitboy suggested / wrote to HexString.DATA[7], but when I CONCAT the edited string to another string, it doesn't contain the value we pushed to it. Reading the HexString variable in the controller tags, it does contain the value we want but it doesn't carry over when concatenation is used, weird? I then thought ah yeah the length would be wrong so edited the .LEN to be 8, that worked, so very well done, great answer and thank you both!

 

[Subsea7]

Gentlemen, a new problem arises. If the hex string has non numeric chars for example 7F, then the STOD fails to put the proper value in, so it becomes 7, then the BCD TOD sends 07 which becomes $07 and the string is no longer correct. This is driving me crazy.

I understand why the STOD fails, but is there a way around that problem? Can't send a non-numeric string to a DINT...

 

[drbitboy]

Wait a minute, you are using STOD to convert strings with two decimal digit characters to an integer? And then treating that integer as a BCD vaue to convert it to the correct binary value in the integer? And then sometimes those character digits are not decimal digits, but are the hexadecimal digits A, B, C, D, E, or F?

If that is the case, then start over. You need to parse the hex string as a hex string, not as a decimal string. Every hexadecimal character in that string represents a value from 0-15 decimal. Convert each hexadecimal character to its value (take its ASCII code, which will be either 48-57 decimal for the digits '0' through '9' with values 0 through 9 decimal, or 65-70 decimal for the digits 'A' through 'F with values 10 through 15 decimal). Multiply the converted value of the first character by 16 and add the value of the second character. For example, start with '7F' in two-hexadecimal-character string s2:

• Value of s2.DATA[0]will be 55 decimal (ASCII code for '7')
  • SUB s2.DATA[0] 48 v1 ;;; subtract 48 decimal from SINT value of first character, result puts 7 (=55 - 48) decimal into DINT v1
  • 7 is less than 10, so do nothing else
  • MUL v1 16 v1 ;;; multiply v1 by 16 because it is the first of two hex characters; result puts 112 (=7 x 16) decimal into DINT v1)
• Value of s2.DATA[1]will be 70 decimal (ASCII code for 'F')
  • SUB s2.DATA[1] 48 v2 ;;; subtract 48 decimal from SINT value of first character, result puts 22 (=70 - 48) decimal into DINT v2
  • 22 is greater than 10, so subtract another 7:
    • SUB v2 7 v2 ;;; result puts 15 (=22-7) decimal into DINT v2
  • ADD v1 v2 other_string.DATA ;;; add v1 to v2, moves result 127 (=112 + 15), which ASCII code equivalent to hexadecimal string '7H', to final target string
    

It would make sense to write an AOI to do most of that, or perhaps just the conversion from a single hex character to its corresponding 0-15 decimal value.

 

[drbitboy]

There might be a better way to do that; I suggest you search the 1756 manual for the word "hexadecimal"

 

[drbitboy]

You don't need v1 and v2, the following three rungs should convert a two-hexadecimal-string s2 to the corresponding binary value in tag v:

• SUB s2.DATA[0] 48 v
  • XIC s2.DATA[0].6 SUB v 7 v
• MUL v 16 v
• ADD s2.DATA[1] v v
  • SUB v 48 v
    • XIC s2.DATA[1].6 SUB SUB v 7 v