News:

  • July 28, 2026, 02:00:55 PM

Login with username, password and session length

Author Topic: Strings and ascii encoding  (Read 35560 times)

CReese

  • Hero Member
  • *****
  • Posts: 184
Strings and ascii encoding
« on: July 08, 2013, 06:48:48 PM »
Hello again.

I've got a string struct that I'd like to convert into a number that I can publish to a MHR register, then read it from a screen and interpret as a string.

How do I suitably encode my string? STR2INT does not seem to be what I'm looking for, and PUBLISH doesn't appear to take string inputs.

Thanks,
C

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6169
  • Yes Pinky, Do-more will control the world!
Re: Strings and ascii encoding
« Reply #1 on: July 08, 2013, 07:54:19 PM »
Use STRGETB to copy raw bytes out of the string. We are looking at adding some string friendly Modbus master instructions, but that will be down the road.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

plcnut

  • Hero Member
  • *****
  • Posts: 814
    • premiersi.com
Re: Strings and ascii encoding
« Reply #2 on: July 09, 2013, 07:19:08 AM »
You can also use STRSUB to extract the data from the string, and then STR2INT to convert it. Take a look in the sample programs: http://forum.hosteng.com/index.php/topic,1013.0.html
at Bobo's http client example to see how it is implemented.
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6169
  • Yes Pinky, Do-more will control the world!
Re: Strings and ascii encoding
« Reply #3 on: July 09, 2013, 10:07:22 AM »
Don't know for sure what he is actually needing, but he stated that he wanted to publish to an MHR a value that would be interpreted as a string. I took that to mean ASCII data, which it is already, so should just require extraction from the string. But there are a dizzying array of ways and formats with numeric and/or string data, so I could be very wrong. I'm sure Do-more can handle it though. ;)
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

plcnut

  • Hero Member
  • *****
  • Posts: 814
    • premiersi.com
Re: Strings and ascii encoding
« Reply #4 on: July 09, 2013, 10:11:05 AM »
and interpret as a string.
Ummm, that little line COULD make a little bit of a difference, couldn't it?!
 ::)
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

CReese

  • Hero Member
  • *****
  • Posts: 184
Re: Strings and ascii encoding
« Reply #5 on: July 09, 2013, 10:40:32 AM »
Bob was right. Now I just need my screen to play nice. Are we doing one byte per character?

CReese

  • Hero Member
  • *****
  • Posts: 184
Re: Strings and ascii encoding
« Reply #6 on: July 09, 2013, 10:47:48 AM »
I'm a little confused. Typically you would use a byte per character. However, the MHR registers are signed words that are 15 bits plus a sign byte. It looks, however, as if I'm getting two characters into each MHR register. How does this work?

plcnut

  • Hero Member
  • *****
  • Posts: 814
    • premiersi.com
Re: Strings and ascii encoding
« Reply #7 on: July 09, 2013, 11:10:10 AM »
Each character uses 1 byte, each MHR is 1 Word (2 bytes in a word).
If you only want 1 character per word then use casting ie: MHR:B0 or MHR:B1
Go to the Element browser and click the "More" button at the bottom to see the options.
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

b_carlton

  • Internal Dev
  • Hero Member
  • ****
  • Posts: 606
    • thePLCguy
Re: Strings and ascii encoding
« Reply #8 on: July 09, 2013, 11:11:54 AM »
it seems like there is some confusion all around.
Quote
I've got a string struct
Does this contain the ASCII representation of a number?

If it is a number do you want an HMI
Quote
then read it from a screen
to be the final destination of this information?

It seems like you were suggesting using STR2INT (SSx -> Dx) but said
Quote
does not seem to be what I'm looking for
. Why? Did it not work?

Quote
PUBLISH doesn't appear to take string inputs
Why are you talking about strings at this point? Wouldn't you PUBLISH (Dx -> MHRx).

Then the 'screen' would use the Modbus protocol to read MHRx and display its value.

An output is a PLC's way of getting its inputs to change.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6169
  • Yes Pinky, Do-more will control the world!
Re: Strings and ascii encoding
« Reply #9 on: July 09, 2013, 11:17:42 AM »
I'm a little confused. Typically you would use a byte per character. However, the MHR registers are signed words that are 15 bits plus a sign byte. It looks, however, as if I'm getting two characters into each MHR register. How does this work?

MHR registers are 16 bit two's complement...not 15 bit plus sign. But the integer encoding isn't relevant when the memory is being reinterpreted as string. The key point is 16 bit = 2 bytes = 2 characters.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

CReese

  • Hero Member
  • *****
  • Posts: 184
Re: Strings and ascii encoding
« Reply #10 on: July 09, 2013, 11:36:34 AM »
it seems like there is some confusion all around.
Quote
I've got a string struct
Does this contain the ASCII representation of a number?

If it is a number do you want an HMI
Quote
then read it from a screen
to be the final destination of this information?

It seems like you were suggesting using STR2INT (SSx -> Dx) but said
Quote
does not seem to be what I'm looking for
. Why? Did it not work?

Quote
PUBLISH doesn't appear to take string inputs
Why are you talking about strings at this point? Wouldn't you PUBLISH (Dx -> MHRx).

Then the 'screen' would use the Modbus protocol to read MHRx and display its value.


The data are string format within the plc. STR2INT would be useful if I had a string representation of a numerical value I wished to manipulate, e.g. '123456' within SS0 or otherwise. That is not the case. I need to take string format strings, encode them into ASCII byte representations, and then have the screen read the data from the MHR registers.

CReese

  • Hero Member
  • *****
  • Posts: 184
Re: Strings and ascii encoding
« Reply #11 on: July 09, 2013, 11:39:20 AM »
Last question: what is the easiest way to reverse the bytes within each of the word (convert to reverse ASCII)? My screen is reading strings like '01234567' as '10325476' and it has no option to reverse on read.

Thanks guys!
C

plcnut

  • Hero Member
  • *****
  • Posts: 814
    • premiersi.com
Re: Strings and ascii encoding
« Reply #12 on: July 09, 2013, 11:40:24 AM »
SWAPB
Circumstances don't determine who we are, they only reveal it.

~Jason Wolthuis
Premier Systems Integration, LLC
http://premiersi.com

CReese

  • Hero Member
  • *****
  • Posts: 184
Re: Strings and ascii encoding
« Reply #13 on: July 09, 2013, 11:51:45 AM »
Rather than do that byte by byte, I used an intermediate ascii name block, then reversed using PUBLISH to the MHR registers. Triple the required memory, but I'll clean it up later if necessary.

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6169
  • Yes Pinky, Do-more will control the world!
Re: Strings and ascii encoding
« Reply #14 on: July 09, 2013, 11:59:10 AM »
SWAPB does a range, but would still require the source and destination to be different. It's pretty much a wash.

Part of our task to look into better string handling in Modbus was also to consider how we could do a better job of simplifying what you are doing right now. It seems to be a pretty common theme, and I'm sure we could hack together an extension to PUBLISH/SUBSCRIB or a dedicated instruction to move bytes from strings into other memory and swap bytes as required. But for now, it is a 'n' step process.
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO