I am limited by a complex existing program written by Germans, in STL, in 2004, who probably enjoyed using Step5.
I have a series of data to move around that eventually gets dumped into a DB that goes out to a PC but this same data needs to also go out to a local printer.
The DB has an array of bytes which hold one char each in hex. Such that ASCii "9" is in the DB as B#H#39.
I also have several other ASCII conversion situations, this is just one example.
Here is the question (using S7, preferably LAD):
I understand the easy way to get ASCii 5 to show up as HEX or DEC 5.
But what about "C"?
All the blocks either use only char or only string data types and nothing just works from one ASCii char to a hex byte.
I want a simple FC or FB that takes a char in and give a hex byte out. I am ok with using a FB and leaving the result in a STAT. I can then move the block of STSTs out to the other DB directly.
If I get ASCii 5, I can use ATH but that gives a hex 5 not the hex value of ASCii 5 which is 35. So for 0-9 ASCii it is a matter of ATH plus 30 to byte, but wait, ATH wont take a char......DOH.
So many roadblocks in S7, I forgot how fun this is.
I could use correlate table, but it returns anything equal to or greater than the input, which could be an issue.
Almost.
0-9 doesn't seem to difficult to get through, but then I have some letters. I need to convert "A" or "C" for example and get hex 41 and hex 43.
A spreadsheet would be the way, with one column ASCii and the next column HEX , then search for your ASCii in column one and use that index on column 2 and get your answer. Not elegant maybe, and not formulaic, but effective.
Arrays have to be all the same DT, can't use one column char and the other BYTE.
Maybe I can make a DT with an array of chars and an array of BYTEs. Then table find the first array, get the index, add the offset to get the corresponding value from the second array.
List all ASCii chars in the first array, then search for the input char in the char array.
Get index of where found, apply index plus offset, return value in second array of hex BYTEs.
Even that is full of issues. And it sounds simple. Would be a snap in my other PLCs. Would take abound 10 minutes. This is on my second day, granted I am not familiar with converting ASCii in S7, but it seems abit much.
Maybe there is a simple way, I haven't found yet.
Would be nice to have DBs with columns like a spreadsheet where a row of multiple data types could be related to each other by row number.
Simple version:
How does one convert an ASCii char, into a BYTE with the ASCii hex value in it?
"A" in, (some FC or FB) "H#41" BYTE out
I would make that into a function, then call the FC in an FB the 36 times I need and put the result in 36 BYTEs of STAT memory, then blkmov all the STATs to the other DB BYTE array.
This is probably easier than I am making it seem. Let me add, there is no possibility to "just do something else", the CHARs must be the HEX value of the ASCii and in a BYTE.
The current program was written to do this in other areas, but they only deal with numbers 0-9, that would be easier. I need numbers and letters.
Thanks all.
I have a series of data to move around that eventually gets dumped into a DB that goes out to a PC but this same data needs to also go out to a local printer.
The DB has an array of bytes which hold one char each in hex. Such that ASCii "9" is in the DB as B#H#39.
I also have several other ASCII conversion situations, this is just one example.
Here is the question (using S7, preferably LAD):
I understand the easy way to get ASCii 5 to show up as HEX or DEC 5.
But what about "C"?
All the blocks either use only char or only string data types and nothing just works from one ASCii char to a hex byte.
I want a simple FC or FB that takes a char in and give a hex byte out. I am ok with using a FB and leaving the result in a STAT. I can then move the block of STSTs out to the other DB directly.
If I get ASCii 5, I can use ATH but that gives a hex 5 not the hex value of ASCii 5 which is 35. So for 0-9 ASCii it is a matter of ATH plus 30 to byte, but wait, ATH wont take a char......DOH.
So many roadblocks in S7, I forgot how fun this is.
I could use correlate table, but it returns anything equal to or greater than the input, which could be an issue.
Almost.
0-9 doesn't seem to difficult to get through, but then I have some letters. I need to convert "A" or "C" for example and get hex 41 and hex 43.
A spreadsheet would be the way, with one column ASCii and the next column HEX , then search for your ASCii in column one and use that index on column 2 and get your answer. Not elegant maybe, and not formulaic, but effective.
Arrays have to be all the same DT, can't use one column char and the other BYTE.
Maybe I can make a DT with an array of chars and an array of BYTEs. Then table find the first array, get the index, add the offset to get the corresponding value from the second array.
List all ASCii chars in the first array, then search for the input char in the char array.
Get index of where found, apply index plus offset, return value in second array of hex BYTEs.
Even that is full of issues. And it sounds simple. Would be a snap in my other PLCs. Would take abound 10 minutes. This is on my second day, granted I am not familiar with converting ASCii in S7, but it seems abit much.
Maybe there is a simple way, I haven't found yet.
Would be nice to have DBs with columns like a spreadsheet where a row of multiple data types could be related to each other by row number.
Simple version:
How does one convert an ASCii char, into a BYTE with the ASCii hex value in it?
"A" in, (some FC or FB) "H#41" BYTE out
I would make that into a function, then call the FC in an FB the 36 times I need and put the result in 36 BYTEs of STAT memory, then blkmov all the STATs to the other DB BYTE array.
This is probably easier than I am making it seem. Let me add, there is no possibility to "just do something else", the CHARs must be the HEX value of the ASCii and in a BYTE.
The current program was written to do this in other areas, but they only deal with numbers 0-9, that would be easier. I need numbers and letters.
Thanks all.