Streamout Questions

[DLTimmons]

I'm work with serial data that is being sent to and received form a PC. This is currently run on a WinPLC so I know the pc side is working correctly. I have one streamin box and 4 streamout boxes three are in stages in one program the other is a seperate program that called when I need to send a response then exits the program on compleation of the streamout. I will need more streamout boxes for the complete program.

I found that with the streamout in a seperate program will not work I moved the forth into a stage in the first program and it works just like I would expect. I need aaccess to the out going port from different location. I currently do this with the WinPLC.

Can the serial port run in full duplex that is out going messages at the same time there are incoming? And do all the streamout have to be in the same program? Like wise does the streamin and streamout have to be in the same program?

 

[plcnut]

I have streamins and streamouts in different programs without a problem (using a SERIO4).

[DLTimmons]

I'm using only one physical port I read it in only one place but need to it write from serveral different places in the project

[plcnut]

I'm not sure on the full duplex part.
I used stages for all of my communications, and only jump from one to the next when the STREAM instructions have completed.
Also make sure that you use a compare contact to monitor the INPUT QUEUE to make sure you have data in the buffer before opening a STREAMIN, that way the port is not tied up, because once you enable the streamin you cannot terminate it without causing trouble (until it times out). Hope this helps you.

EDIT: See Bobs post below on the incoming queue, I remembered wrong.

[BobO]

The physical port is full duplex, but Do-more's logical device is locked by each instruction and can only be used by one instruction at a time. The instruction itself doesn't do the port read or write though, it just interacts with the low level device driver. I prefer to write my protocols by waiting for data to be in the input queue before calling STREAMIN, so I don't tie up the device. You can determine the number of bytes sitting in the input queue through the structure associated with the port. For 'Port1' the field would be 'Port1.InQueue'.

[DLTimmons]

Do I understand this correctly that a streamout and a streamin on the same port can not be active at the same time. If so how would be the best way to interlock them? 

[plcnut]

I would probably have a stage with two rungs in it:
The first would monitor the .inqueue and jump to another stage to handle streamin.
The second would monitor a bit (that is set in another part of the program) that would jump to a stage to handle streamout.
Whenever either of these operations are complete, then jump back to this stage.

[BobO]

Do I understand this correctly that a streamout and a streamin on the same port can not be active at the same time. If so how would be the best way to interlock them? 

We handle the interlocking internally, there is nothing you need to do.

If you start a STREAMIN with a timeout, then start a STREAMOUT, the STREAMOUT will latch the request and process it as soon as the STREAMIN completes. Since the data is being captured by the low level device regardless of whether you have a pending STREAMIN, I generally just camp on .InQueue input I am ready to read the data, then read it without a timeout.

[plcnut]

Since the data is being captured by the low level device regardless of whether you have a pending STREAMIN, I generally just camp on .InQueue input I am ready to read the data, then read it without a timeout.

So the serial port receiving buffer operates independent of the CPU scan and will pack in data until I use a STREAMIN to get it? (until the buffer is full of course)

[DLTimmons]

Got the streamout working from different programs!!  You have to use a Yield after calling the other program.

It get harder for old dogs to learn new tricks so bare with me

I do get these messages now

[Message]   CommandRead@9   M331 Asynchronous instruction STREAMIN used in code-block with 6 yielding instructions (YIELD at @24  YIELD at @144  YIELD at @231  YIELD at @289  YIELD at @304...)
[Message]   CommandRead@409   M331 Asynchronous instruction STREAMOUT used in code-block with 6 yielding instructions (YIELD at @24  YIELD at @144  YIELD at @231  YIELD at @289  YIELD at @304...)
[Message]   CommandRead@508   M331 Asynchronous instruction STREAMOUT used in code-block with 6 yielding instructions (YIELD at @24  YIELD at @144  YIELD at @231  YIELD at @289  YIELD at @304...)

[BobO]

Got the streamout working from different programs!!  You have to use a Yield after calling the other program.

It get harder for old dogs to learn new tricks so bare with me

That may be working, but not for the right reason. Programs are not called, they are enabled to run. If you want to invoke a program from within a Stage of another program, look at the attached program. The same thing works for Tasks.

[BobO]

So the serial port receiving buffer operates independent of the CPU scan and will pack in data until I use a STREAMIN to get it? (until the buffer is full of course)

Yep.

[plcnut]

So the serial port receiving buffer operates independent of the CPU scan and will pack in data until I use a STREAMIN to get it? (until the buffer is full of course)

Yep.

Cool. That is very helpful to know. 

[DLTimmons]

That may be working, but not for the right reason. Programs are not called, they are enabled to run. If you want to invoke a program from within a Stage of another program, look at the attached program. The same thing works for Tasks.

That did the trick and cleared up the messages. Now to get the bottom of the double responses

[BobO]

That did the trick and cleared up the messages. Now to get the bottom of the double responses

Good.

The messages were just warning you that YIELD instructions can cause issues with certain multi-scan or async instructions. There is nothing wrong with what you were doing, but there can be side-effects and it is important to know what those are.