Problem with HEX and NUM4 function

[FET_Destroyer]

Hello Guys, I'm frustrated, I cannot work with these two functions :s I have some ascii string on HMI saved in the D95-d96 register but by some reason I cannot convert it to uint. I Think i'm using these functions correctly. Can somebody help me?

[Mendon Systems]

That HEX number designator doesn't seem to work the way it is described. Note --- If you have any imbedded null bytes (#00) that terminates the string and will cause the functions not to work. Try this: Edited December 12, 2013 by Mendon Systems

[FET_Destroyer]

Hello Mendon, As you can see I think all the data coming from HMI is correct. But still nothing at the hex function, is it because that end (#00) character on the end of D96?? How can I do this? Can I shift 8 bits to the right, but in that way the #00 will be in the beginning instead of being in the end.

[IO_Rack]

In your example, is the data from the HMI 123? If so, then why is the '1' in the upper byte of D96? What does it look like if you input 1234?

[Mendon Systems]

I am quite sure that the null in the low byte of D96 is causing your problem. If the HMI is going to store the data that way you may have to use several rungs and read each character individually.

[FET_Destroyer]

@IO_Rack, The data is 231. @Mendon, There is no fast way to do it? I try to make the conversion on the NS5 hmi but I rather prefer to have all on the PLC.

[Mendon Systems]

There probably is. Will the data always be 3 digits long?? It gets a LOT more complex if it is a variable length string. IF it is always 3 digits then this should work. edit: I did a bit more tweaking. If you change the first digit designator to #11 you can get rid of the NASL instruction. String-Hex.pdf Edited December 13, 2013 by Mendon Systems

[BITS N BYTES]

You are using TWO words D95-D96 and trying to convert it to UINT. TWO words are UDINT, I believe you need to to use NUM8 for your conversion.

[IO_Rack]

I guess there is no easy method to accomplish this. I agree with Mendon Systems that the NULL character is an issue. Where is your data stored in the NS5? I have an example of converting it from a String Display & Input object and of variable length. In this case I was able to select an option to convert 'blanks' to ASCII Spaces. Not sure if this will solve your issue but you may find some useful techniques. ASCII_to_BCD.cxp Edited December 18, 2013 by IO_Rack

[Mendon Systems]

Actually ....... your "brute force" approach is a good way to solve that problem!! I like it!

[IO_Rack]

This one will work with NULL characters. I'm not a big fan of ST language but it works. There is an issue where the 4 character (2 Word) address runs into the upper byte of the 3rd Word. I don't know why. For instance, if you populate D805 (upper byte), then the result in D901 will be affected.

[professor_jonny]

There is also concat in st for joining strings i dont know if it suits your application: HMI_STRING_WITH_NO _GAPS:=CONCAT(HMI_STRING_A,HMI_STRING_B,HMI_STRING_C,HMI_STRING_D); OUTPUT_STRING:=STRING_TO_INT(HMI_STRING_WITH_NO _GAPS_NUMBER), or this for filling in the gaps : INSERSION POINT:= FIND(HMI_STRING_WITH_WITH_GAPS,00); HMI_STRING_WITH_NO _GAPS:= REPLACE(HMI_STRING_WITH_WITH_GAPS,NULL_CHAR,2,INSERSION POINT) Edited December 20, 2013 by professor_jonny

[FET_Destroyer]

Hello Guys, Thanks for all the replies. In the end I used the ST string_to_uint function, it is simple enough and it does the job. I just created some internals variables linked with the double words were the strings were being saved.