STREAMIN/OUT Issues

[RBPLC]

I'm using a BRX to read from a flow meter that accepts serial commands in the form of ASCII characters. I was reading two parameters from the flow meter and using an index to cycle through the two commands to STREAMOUT the command and STREAMIN the data values using stages. All of these seemed to be working without issue. Stages were set up so that they would continue to attempt to re-establish communications in the event of a comms loss. Over the weekend, comms was lost with the flow meter (I've seen this several times with the flow meter and do not know what the root cause of the issue is). The flow meter was power cycled and when it powered back up, communications was automatically restored. The issue was that the value that should have been in ReadInValue0 was being stored in ReadInValue1 and the value that should have been in ReadValue1 was being stored in ReadValue0. I've spent about two hours this morning trying to figure out what is going on with this. I even went so far as to eliminate the indexed reads to see if the streamed in data would go to the correct memory locations. Suffice it to say, they did not. I power cycled the flower meter and when it came back on, read-in data was still in incorrect memory locations. I put the PLC in stop mode and transitioned back to run mode, this did not fix the issue. I then physically pulled the connector from the SERIO module and when I plugged in back in, read-in values were stored in their correct memory locations. I would like to know why/how the read-in values were being stored in the wrong memory locations and how to prevent this. 

UPDATE: After more troubleshooting, I can reproduce the described issue every time by powering off the flow meter. I have incorporated the DEVCLEAR function and this seems to get the incoming data back in the correct memory locations. 

[franji1]

Not sure of your logic, but if you are doing indirect/variable addressing, realize that you must maintain the state/values of all parameters during the ENTIRE ASYNCHRONOUS LIFETIME OF THE REQUEST, whether they're variable remote addresses, array indexed Local Address, array indexed parsing of the response packet, whatever.

Since you are doing STREAMOUT/STREAMIN comm type requests, make THAT ATOMIC.  Do NOT CHANGE ANYTHING UNTIL THE ENTIRE REQUESTION FINISHES SUCCESSFULLY or IN ERROR.

The question becomes, if you get an error on Request A STREAMOUT, do you keep trying to do STREAMOUT A until it succeeds, or do you always move on to Request A STREAMIN?  Or do you move on to Request "B" STREAMOUT regardless on whether Request "A" errored out?  Both your failed and success behaviors on A and B need to be timed/sequenced precisely, on both the STREAMOUT cycle and the STREAMIN cycle.

If one of those gets out of synch (success handling/parsing vs. error handling/reporting, A vs. B handling), you could get some strange behavior.