Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: DLTimmons on February 26, 2013, 01:54:15 PM
-
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?
-
I have streamins and streamouts in different programs without a problem (using a SERIO4).
-
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
-
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.
-
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'.
-
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?
-
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.
-
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.
-
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)
-
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...)
-
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.
-
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.
-
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. :)
-
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
-
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.
-
BobO
Thanks
It always a trade off the more power you give something the more there is to learn. From what I seen so far you have a good CPU here with the D0-More
Donnie
-
It always a trade off the more power you give something the more there is to learn. From what I seen so far you have a good CPU here with the D0-More
There definitely is. We tried very hard to strike a balance between a controller that would meet ADC customers where they are, and one that can also expand the market and embrace the needs of the future. The result is a PLC that can do basic stuff pretty well and do some super complicated stuff too. Time will tell whether we struck the right balance.