serio.inqueue Interpretation

[sgsims]

I am having trouble understanding the value held from the serio.inqueue variable.  The documentation says it is an unsigned integer that reflects the # of bytes of data in the inqueue variable.

I used the streamin instruction to receive a string of "False"  the bit representation of the ASCII string of "False"  is 0100 0110 0110 0001 0110 1100 0111 0011 0110 0101.  I would call that 4 bytes of data so I would expect the inqueue variable to return a value of 4 but instead it returns a value of 1.

Scott

[franji1]

Not sure how your STREAMIN is set up to "terminate".

One possible scenario, if you have it terminating on a Length of 4, when it's enabled and you receive "FALSE" (which is 5 characters), it would read in the 4 "FALS" into your buffer, then leave the .inqueue value equal to 1.

How do you have your STREAMIN termination set up?

[sgsims]

Thanks Franji,  The STREAMIN instruction is set to ? complete? when a delimiter is received?.the length option is unchecked,

But question about the inqueue,  is the queue before the STREAMIN instruction reads the queue?  If so why would any of the settings of the STREAMIN instruction matter?

[BobO]

Thanks Franji,  The STREAMIN instruction is set to ? complete? when a delimiter is received?.the length option is unchecked,

But question about the inqueue,  is the queue before the STREAMIN instruction reads the queue?  If so why would any of the settings of the STREAMIN instruction matter?

The settings of STREAMIN govern the behavior of STREAMIN. The .InQueue member is simply giving you status about what's available for STREAMIN to read.

I personally tend to write my comm code by checking the .InQueue member first and only invoking STREAMIN when I know the data is there.

SGn
if Stream.InQueue >= SomeLevelThatMakesSense then STREAMIN

In cases where you don't know the length of the data, you can still use this method to look for the shortest expected data and shorten the timeout to be slightly longer than what it should take to send the longest expected data. Again, personal preference, but I don't like to sit in a STREAMIN without a timeout. If the data didn't show up in a reasonable time, it's always preferable to fall out, clear the buffer, and restart.

[sgsims]

Thanks Bob....Yes I agree about using a rung of conditional logic using the inqueue member before executing the streamin instruction.

My understanding,  correct perhaps,  is that when data is sent to the BRX Serial port from the outside world it is handled at a low level by the serial port chip and sits there until the streamin instruction is executed at which point the data bits are copied to the PLC memory location specified in the Streamin instruction.  Upon succesful or unsuccessful completion of the streamin instruction the data in the serialport chip is cleared.

Is that sort of how that goes?

[BobO]

Pretty much. It's read from hardware into the stream queue, which is what .InQueue is reporting. STREAMIN then removes bytes from the queue.

[sgsims]

Okay I see what I was doing incorrectly.  I was trying to use the copy instruction to copy the inqueue structure bits to a memory location using a element count of 1.  When I isolated the streamin instruction so as to not execute I could see the inqueue count as expected. 

Guess I need to read up regarding how to use the copy instruction correctly.