How to trend Serial Streamin Instruction

[Dean]

Please understand...it is possible for this to work with far less effort, but what we are describing is how to make it robust.

100% agree. This is the lesson I have taken from this situation. This segment needs error proofing. I guess I just need to start from scratch, and rebuild this segment. A couple questions if I may:
Lets say we have a string like this
abc123CR123abcCR
I Streamin when InQ >0 and with 1 delimiter 0xOD into SS0
On Success I run another STREAMIN 1 Delimiter 0x0D into SS1
I should get SS0 = abc123 and SS1 = 123abc Right?
According to the help files, once the first chunk is moved to the destination, then whatever is left in the buffer gets shifted to the beginning, so I think I'm interpreting this properly.
If so, I can separate each chunk into it's own string, and check to see if it starts with the correct character. If so, move on to parsing. Once parsing is done, clear the device, and go back to step 1. If not, clear all the strings, clear the device, and go back to step 1. Does this make sense as a strategy?

[BobO]

abc123CR123abcCR
I Streamin when InQ >0 and with 1 delimiter 0xOD into SS0
On Success I run another STREAMIN 1 Delimiter 0x0D into SS1
I should get SS0 = abc123 and SS1 = 123abc Right?

Yes.

I Streamin when InQ >0 and with 1 delimiter 0xOD into SS0
According to the help files, once the first chunk is moved to the destination, then whatever is left in the buffer gets shifted to the beginning, so I think I'm interpreting this properly.

A STREAM is a buffered sequence of characters. As you call STREAMIN, you are removing characters from that sequence. STREAMIN has up to three ways it can terminate: by receiving a count, by encountering a terminator, and by timing out. .InQueue tells you the total number of characters currently sitting in the queue, making it possible to build the basic protocol flow outside of the STREAMIN, and just using the STREAMIN as the way to access the data. If you know the length expected, you can spin on .InQueue until the expected number has arrived, then call STREAMIN. In your case, waiting until .InQueue is non-zero, then calling STREAMIN with the terminator works fine too. I like the length approach when possible, but the terminator approach is good too.

A PACKET is a chunk of data. Once read, the entire packet is removed, even if you only asked for the first byte.

If so, I can separate each chunk into it's own string, and check to see if it starts with the correct character. If so, move on to parsing. Once parsing is done, clear the device, and go back to step 1. If not, clear all the strings, clear the device, and go back to step 1. Does this make sense as a strategy?

You are tokenizing as you go. That should work fine.

[Dean]

Thanks to everyone for your guidance. I believe I'm on the right track here. I've built a quick sandbox application, and it appears to be working as described. If I get a partial transmission, or lose a character or two, one or more of the sub strings gets whacked out enough to fail the integrity testing. This causes the program to pitch the entire transmission, clear the buffer and start over. That said, I think my final application will only throw out whichever sub string(s) fail integrity testing and keep those that pass. This will help diagnose when problems come up. Again, I really appreciate the help. This forum is an invaluable resource.

[BobO]

Thanks to everyone for your guidance. I believe I'm on the right track here. I've built a quick sandbox application, and it appears to be working as described. If I get a partial transmission, or lose a character or two, one or more of the sub strings gets whacked out enough to fail the integrity testing. This causes the program to pitch the entire transmission, clear the buffer and start over. That said, I think my final application will only throw out whichever sub string(s) fail integrity testing and keep those that pass. This will help diagnose when problems come up. Again, I really appreciate the help. This forum is an invaluable resource.

Perfect. From not understanding the concept of 'framing' to a protocol expert in just a few days! That's awesome.

I've written comm code since shortly after the earth cooled and we designed Do-more comms with that experience in mind. We often joke about the fact that it's easier to develop a protocol in this PLC than in virtually any environment I've ever worked with. It's not optimal for some things, but the basics of getting data in and out of a serial or Ethernet port are far, far easier than doing so using C++ in a PC. It really makes me happy to see users get good results!

[Dean]

From not understanding the concept of 'framing' to a protocol expert in just a few days!

If only that were true, but with everyone's help, I have put a few more wrenches in the toolbox.

[BobO]

From not understanding the concept of 'framing' to a protocol expert in just a few days!

If only that were true, but with everyone's help, I have put a few more wrenches in the toolbox.

Don't sell yourself short. You came up to speed pretty quick.

With what you understand now, consider downloading the DirectNet server sample app. If you can follow what I've done there, you've added some nice tools to the toolbox.

[Dean]

Bob,

I spent a few minutes scanning through your example, and it mostly reminded me of how little I actually know about this stuff. Yikes! I have a couple questions if I may for anyone that may have a minute to look at what I'm doing. I have attached my most recent sandbox attempt. My question is you will notice that Stage 6 has a In Success Jump instruction to Stage 0. It never seems to make the jump to Stage 0. I know that the conditions are met on the STREAMIN, as there is a carriage return. Here is a typical example of SS55 as Quoted ASCII

"D00=E4     0.0000  ppmO3 07 R=   25000 $0D"

. You'll notice the escaped CR, so it should trigger the On Success bit. I have also attached a screen shot of a trend of all 6 stages. You will notice that Stage 0 never fires. What am I not understanding here? I mean it works, but shouldn't I see Stage 0 actually execute?

[BobO]

It may only be in stage 0 for a fraction of a scan...and comms are performed at the bottom of the scan. This in addition to the fact that trends are polled...not guaranteed to get ever scan.

Put an INC instruction in each stage, conditioned with a rising edge contact.

[Dean]

Well that's an interesting tool. Thank you. I'll definitely remember this trick.

[franji1]

Well that's an interesting tool.

Edge triggered INCs work GREAT for seeing some kind of "heart beat" for code that may be executing just 1 scan (or even sub-scan!).