S7-1500 combining and converting characters

5 bytes received, must be converted to 10 characters.
From post #9:
Only 0-9, A-F are allowed.
W#16#ABCDEF00 must be converted to series of CHARs 'a', 'b', 'c', 'd', 'e', 'f', '0', '0'.

To me it sounds as if there is an ID hex value (from an RFID code reader ?) that must be output as something human readable, i.e. a series of CHARs or a STRING. Maybe for a label printer or to display on an HMI ?

The HTA instruction (hex to ASCII STRING) should do the trick.
In S7-1500 (but not S7-1200) you can input long words as the source (LINT or LWORD), or if it is more convenient an array of BYTEs.

This is what he posted:
I cannot modify it and change it, my task is to reverse this, as I want to write my own string. So I have to reverse this behavior and create a char from 2 values. It works... up to some point.
So it appears the RFID sends 5 chars "aA35Z" for example this is currently decoded as chars of the hex values of each char i.e. "616533355A" what it appears is that he wants to reverse this so that the ascii chars "6","1" become "a" & "6","5" become "A" & so on, But looking at further posts all he is doing is trying to convert his own string of Hex (in string form) back to ascii chars
This is not what he is saying in the first post. it indicates he has an ascii string of 10 chars (ascii chars that show the hex value and wants to convert this back to a 5 char string, now this gets confusing see pic.
perhaps the OP needs to post a string he wants to convert & the expected result i.e. is it "aA35Z" to "616533355A" or vice versa this does not make sense he cannot convert 10 ascii chars to 5 except if they are an ascii representation of the hex values, why if he already has them. if it is to compare them then there are two scenarios,
1. He generates as a string "616533355A" but as the original from the RFID are already converted into a string representation of the Hex values then it's just a string compare ?.
It looks like the OP is trying to convert any 10 ascii chars into the hex representation into 5 chars yes it works for 0-9 A-F but g onwards cannot as these are values above 15 so byte 0 if AB, AC 1F etc. is fine but to put AG cannot be done. I await the OP's response on that one.

adfox said:

That's why I needed to pack the bytes back and put them on RFID.

Click to expand...

Yeah, reading this it seems that he has to take a 10 character STRING or CHAR array (with the content limited to 0-9, A-F) and put it into a 5 BYTE long array, coded as the hex value using the characters of the STRING/CHAR array.
I thought it was the other way around. That the RFID was a reader that provided a HEX value. Now I understand..

drbitboys suggestion of using the ATH instruction should work.

0-9 A-F will work, but there appears to be a 5 char string being read how is converting a 10 string into a 5 char when you could type in a 5 char string directly however, still confused, it looked like the OP tried to use non hex values (if I can call it that), however, looking at what the 5 byte char from the RFID it may be a way of encoding a large hex number into a small string.
It looks like the original software converts this into a string that would be 10 chars long but the hex representation of those original chars, still do not understand why the OP is trying to decode an Ascii string (all be it in hex) into 5 chars, what is it for ?. if it is a compare with a read then just use the original 5 chars, if it is to supply a code for a new RFID how is it programmed into the RFID ?. Still no explanation.
A 5 char string is something I do not understand I believe one standard is 96 bits but probably only a portion of that is used for the ident.

Yes, it is difficult to understand why and what it going on.

It is not the output to the RFID is a BYTE array that is weird.
It is that the starting point is an array of CHARs, and one which must be limited to 0-9, A-F (*).
I the final destination is a BYTE array, why not use a BYTE array all the way ?

Is it because the characters comes from some user-input ? If so, any normal HMI software (including Siemens WinCC) can accept that an user input is entered as a hexadecimal value and also limited to a certain no of digits.

*: This was also what threw me off. I can imagine this requirement if it was for a label printer or something like that. That is why I thought that the RFID was a reader and the input that had to be converted. It has to work the other way, but I cannot imagine the scenario.

All right, thank You all for explanation it was very valuable experience.
Customer said they'll need only 4 digits and that's it.

To explain again RFID can hold 5 bytes.
Customer uses 10 characters part numbering.
They used that function to pack their codes into 5 Bytes RFID by combining 2 chars together using 1 byte.

I was not aware of limits when they requested it and had a limited time for adopting my code on site and I could not take a look what's inside their decoding function because of KnowHow protection, so the only way was trial and error on my side.

Thanks to Your input now I understand the mechanism behind it and well that 4 bit limit.
I don't think that the customer also understands what's happening there.

Again - thank You, I've learned a lot

So the way I see it is the RFID returns a 5 digit string i.e. 1234Z and this is converted to a 10 digit code based on the char version of that hex code.
I.E "313233345A"
So you have two choices input a 5 digit code as per what the RFID and do what ever or you input an ascii string depicting the hex codes so there could never be a character above F
So the input is "1234Z", if you use this as a compare in the PLC no need to convert as just do a string compare with the data comming in.
If you need to input "313233345A" then this could be compared again directly with the decoded hex string as is.
If you needed to convert "1234Z" then you already have the function to do this.
If you input the hex codes then to convert to the 5 digit string you would need to take the first 2 digits, convert to hex as nibbles in a byte then convert to char etc. Your explanation so far is an improvement, however, you have not told us what this "Code" input is for i.e. for comparison with incoming RFID, To write (Program) the RFID.
Anyway, hope our posts have been useful & you manage to solve the issue.

adfox said:

To explain again RFID can hold 5 bytes.
Customer uses 10 characters part numbering.
They used that function to pack their codes into 5 Bytes RFID by combining 2 chars together using 1 byte.

Click to expand...

"can hold 5 bytes" ? What does "hold" mean ? Do you send 5 bytes to the RFID or does the RFID send 5 bytes back ?
Your description does not explain what data goes where.
That is why we are running around in rings and wasting our time.

parky said:

So the way I see it is the RFID returns a 5 digit string i.e. 1234Z and this is converted to a 10 digit code based on the char version of that hex code

Click to expand...

That was what I thought, but in post #7 he writes this:

adfox said:

That's why I needed to pack the bytes back and put them on RFID.

Click to expand...

So he sends the 5 bytes to the RFID.

Does that mean the OP is using the PLC to write a new code to the tags ? how ?
Or is it he is just using it to convert, is there some code written already in the PLC that does it, find this unlikely, what about duplicate tags converting the hex codes to a 5 chars although a bit awkward is possible, if so why does he need to convert chars G & above as it sounds like it is just a reverse i.e. converts 10 chars containing the hex values into the 5 char variables. So how come he is trying to convert g > in banks of 2 into a a 5 char string, I think he has really not got tha hang of this, Looking at the variable table he posted i.e. AB,CD etc.
This bears no resemblance to the ascii conversions of the Hex codes.
A = H41, so instead of HAB, this would be in the realms of Extended codes not something you need on a RFID or type in on an HMI even if it was possible probably find the input field is limited to printable chars within the 127 range.

Hello maybe you need a different en/decoding method, e.g. ISO 17367 which is 6 bit character encoding. Normally RFID reader should support such decoding and your PLC could get a decoding result directly.