String Parsing

[PLChristian]

Hello all, I have string data sent from a balance to a plc. The data cycles through every second or so which is good because it is constantly updating the weight displayed on the scale. However the issue I have is when I parse the data it cycles though and I am getting unwanted characters in the parsed data. Any ideas how I can get the return and line feed values to stop cycling through when I parse ?

 

[celichi]

Just a guess, not much details on hardware or comms.

Is the data landing in the PLC independent to the scan?

Maybe try to copy the data in the registers to something offline for processing/parsing that is not being updated while you are parsing.

Have some code that monitors the string, and when it is different, set a flag, and copy and parse outside of the landing registers.

 

[PLChristian]

So my string data cycles in which is what I want because I'd like the PLC to read data from the scale in live time. The issue is parsing the data to send from the plc to a display. Right now I have to parse the data several times to actually get the desired balance value without the return carage and line feed. How can I get this to just send the desired numerical value part of the string.

 

[celichi]

Okay, I see what you are trying to do.

You want to strip off the header and footer, and just be left with the numbers.

I did a STOR and an STOD, and both stripped off all the formatting...

Then you can convert back to string in needed.

 

[celichi]

STOR or STOD

STOR inData OutDataReal

 

[Ken Roach]

I've read your other posts about using the 1769-ASCII module and getting this data into a String tag.

Is the data coming in consistently with the "ST," as the first three characters ?

Your balance has a tidy fixed-position ASCII string output. The +/- character will always be in the same place, the data values are padded with leading zeroes, and the number of decimal places is fixed.

That's *perfect* for the MID instruction to pull only the string characters related to the value from out of that string.

But first the data has to consistently get into the string at the same position. What is changing or inconsistent with the input string ?

 

[Ken Roach]

Once you have the data coming into the same places all the time, a properly configured MID instruction will grab the data you need from those locations. In this case, the start position is 4, and the length is 9.

If you have to find the first character, you'll probably have to search the string for a "," and add one.

 

[PLChristian]

My string data cycles through perfectly, the issue I am having is that I have parse the data several times before getting the desired characters. Since my data will be outputted onto a display I am concerned when I start parsing I will have undesired characters display before the ones I want displayed appear due to the continuous cycling data strings

 

[PLChristian]

Is there a Function where I can search the string for the "," and have it display the following characters ?

 

[PLChristian]

I guess I am just confused with how to get the string data consistently in the same place when it is cycling through

 

[PLChristian]

Is there a way to get it to cycle just the 17 characters at a time that way they are always in the same locations ?

 

[drbitboy]

Which ASCII read command are you using and what parameters are you passing to it? If possible please point to a page number and a link to the PLC instructions manual you are using.

There is usually a version of ASCII read instructions that reads up to a terminator/delimiter (e.g. <CR><LF>), and sets its done bit when it reads that terminator. So, assuming the device is sending a continual stream of characters like this

x+/-value<CR><LF>x+/-value<CR><LF>x+/-value<CR><LF>x...
​

where <CR><LF> is the terminator and [x] is start of message, and there will never be more than N (in your case 17, or maybe 15) characters between <CR><LF>, then you can then ask that terminator-aware instruction to read N+2 characters, and after a clear-buffer instruction, it will give you something like [ue] on the first read (since clearing the buffer removed the ...value<CR><LF>[x+/-val], so you discard that first result [ue] because it does not start with [x], and then then next read will have the full 17 (or 15) characters [x+/-value] without the <CR><LF>, which you cut after the [x] using MID and then parse the rest using STOR or whatever.

A bit of a run on sentence there, but I hope it's clear.


[Update oh never mind all that, you are already using ARL, which is the line-buffered read. I don't think you need the ABL, just read the stream with ARL, and when [the ARL done bit has a rising edge AND the result starts with the [x]] then parse it via MID/STOR, or if [the ARL done bit has a rising edge AND the result does not start with the [x]], then throw it away because on the next rising edge of the ARL done bit it almost certainly will start with the [x].


The PLC presumably uses a UART, which is always hardware-buffering the current stream; what it does on overflow you don't care because you clear the buffer once at start of program before starting the ARL reads and after that the PLC and ARL checks and drains the UART buffer content frequently enough that it should neither ever overflow again nor ever have more than one [x+/-value<CR><LF>], and even if it does that gets tossed and the second read picks up the full string].

 

[PLChristian]

Ok I got it to work with just setting the delimeters up properly. I was way overthinking the issue, which is typical. Thanks for the help everyone!

 

[Ken Roach]

Please follow-up with whether you were using the ARL or ARD serial port instructions on an older CompactLogix with a built-in Channel 0 serial port, or if you were using the 1769-ASCII module, which has delimiter configurations in its port setup.

I think you were almost there in a previous post where you had <CR> (the default) as the terminator, but you needed <LF> as the terminator because both characters came at the end of every line.

For fun, you can experiment with the FIND instruction, which will locate a string inside another string. Make a search string that is just a comma, then see what position it tells you the comma is in.

When I use FIND and MID, I usually have to test to be sure I get the offsets versus the indexes correct.

The first character of a string is TagName.Data[0], but it is considered "position" 1.

 

[PLChristian]

I am using the AB 1769-ASCII module.