CJ1-SCU21 Serial Buffer

[BITS N BYTES 66]

What is the mechanism/timing for data being received INTO the buffer of Serial port and how is this coordinated withthe PMCR instruction? In my application I have a host connection with no flow control. The host can send unsolicited a message or group of messages any time. Each message has the same header and trailer strings. Does/can the serial port receive strings into its buffer prior to a Receive Message being initiated with a PMCR command OR does the buffer only accept data when the PMCR is active? In some cases there is only a single message sent from the host. In this case defining the message string in the text editor is fairly easy. However with multiple messages I am somewhat confused! What structure should be used in a protocol to achieve this. Multiple steps with identical <h> and <t> but different write variables locations! A single step with N iterations and each iteration writing to different variable locations using the N+y in the variable! Should/can the step WAIT feature be used to sequentially read data out of the buffer? I know these questions may be fairly basic to some, but in my case I cannot find any meaningful examples in the Omron manuals [CX Protocol or the SCU21] that provide any meaningful solutions. Any help would be greatly appreciated. Edited 30 Sep 2005 by BITS N BYTES

[Jay Anthony 118]

I will forward this to our resident expert on unsolicited messages. He can probably help.

[BITS N BYTES 66]

Thanks again Jay - look forward to some answers. To expand further I might receive the following message string in the buffer .........<h>A:fghdse<t>..................<h>B:klsewq<t>.............<h>C:123456<t>..... I need data in A: to move to D100-D102, data in B: to move to D110-D112 and data in C: to move to D120-D122. After reciving this data and processing it with the PMCR I might receive a new string as follows:- .........<h>B:gwityp<t>..................<h>A:lpqys1<t>.............<h>C:k3l5y7<t>..... Once again I need data in A: to move to D100-D102, data in B: to move to D110-D112 and data in C: to move to D120-D122. Hope this helps expalin my dilemna. Thanks

[Jay Anthony 118]

Don't have time to go into it now, but what you need is a maxtrix receive message. I'm sure my PMCR guy will chime in here with a disertation on matrixes. Another thought would be to always receive into the same area and let the PLC indirectly address the DM location based on A, B and C.

[Nibroc 4]

... Yes, you need to set up a matrix of possible recieve messages. Use the wait step (referenced to the matrix), the matrix then performs the appropriate reply I need to rush also, will have a look later and may find an example to post from a running system Nibroc

[PMCR 66]

I will try to address your questions in the order you posted. 1. Getting data into the Buffer. The answer to this question partly depends on which version of CJ1W-SCUxx you are using. Prior to SCUxx-V1 the receive buffer was always flushed when a PMCR was executed from ladder. SCUxx_V1 hardware allows you to select whether or not the buffer is cleared upon execution. This selection is made in the setup of the module (the same place that you select Protocol Macro Mode) for the port. If you configure the port to not flush the buffer, and on a particular PMCR you do want to flush the buffer, you can use a Flush step as the first step of the PMCR. 2. Recieve Maxtrices. A receive matrix is a collection of receive messages called at one time, only one of which will match the string in the receive buffer. EX> RECMSG_A <h>"+"ABCD"+W(DM0,4)+<t> RECMSG_B <h>"+"EFG"+W(DM4,8)+<t> RECMSG_C <h>"+"KYL"+W(DM12,10)+<t> The SCU will compare the data in the receive buffer with each Receive Message in the matrix in order from top to bottom until the first match is found. When a match is found, the SCU exits the Matrix. The comment made by Nibroc regarding the use of a wait step is an excellent point. This can be used if your PLC needs to respond to the unsolicited message from your serial device. There is a wait release bit (N+0.00 for port 1, N+0.08 for port 2) that you turn on in the PLC to release the wait step. There is also a bit (N+9.09 for port 1, N+19.09 for port 2) that indicates that the SCU is on a wait step that needs to be released. See the attached file for an example of how this could be implemented. PMCR_Example.psw

[BITS N BYTES 66]

PMCR Thanx for the response. I am using the latest hardware version of the CJ1-SCU21 so I do have the ability to control flushing of the buffer. What still puzzles me is how unsolicited data is handled under this condition? IF buffer flushing is disabled will the buffer continue to receive new data as it is transmitted into the serial port even though the original data is being processed with a PMCR RECEIVE command? In my example, when a PMCR receive command is active the buffer initially contains:- .........<h>A:fghdse<t>..................<h>B:klsewq<t>.............. If a receive matrix is set up to look for instances of A:[*.*], B:[*.*] or C:[*.*] it will find the first match A:[*.*]. During this event the host sends data for C. Providing a flush command has NOT been issued am I correct in assuming that the buffer now contains the original data PLUS the NEW data? .........<h>A:fghdse<t>..................<h>B:klsewq<t>.............<h>C:123456<t>..... If a flush command IS issued at what point is NEW data written from the host accepted or rejected into the buffer? In other words if the host is sending unsolicited data how can I be sure to capture all data without flushing it out of the buffer? A functional description of the buffer mechanism would be of great help! MATRICES As you state "The SCU will compare the data in the receive buffer with each Receive Message in the matrix in order from top to bottom until the first match is found. When a match is found, the SCU exits the Matrix" What I am trying to do is have the SCU send a message to the host if a match is found in the matrix. Can this be handled solely within the SCU or must there be PLC code that initiates the desired PMCR Send command in response to a match within a matrix? GOALS In general I am attempting to utilize the power of the protocol macros to manage the PMCR Send/Receive messages to the host with a minimim of PLC coding. Each matching RECEIVE case generates a SEND response. If the PCMCR matrix finds a match the desired SEND message is sent, the PCMR then returns to to the matrix, looks up the next matching case and generates another responese etc. etc. If this needs to be handled with PLC code what flags/words are available to monitor a matching matrix case? Once a case is found, if the PMCR calls the matrix again can the case be indexed to the next one through flags/words fromthe PLC? In other words can matrix cases be enabled/disabled via flags/pointers set in the PLC prior to sending the next PMCR comand that starts a matrix search? I will take a good look at your posted Protocol Macro tomorrow. Many thanks for your help. Edited 4 Oct 2005 by BITS N BYTES

[PMCR 66]

I must admit that I have not pushed the new option for flushing the buffer as hard as you currently are doing, but I can give you my understanding. The Receive Buffer will receive data regardless of what the SCU is doing, ie sending, receiving, not running a PMCR, etc. It will not be flushed unless you flush it manually. If 3 consecutive messages are stored in the buffer, the first will be processed by the matrix the first time the matrix step is called. The second message will be serviced the second time the matrix is called, etc. Please see the attached file for a solution. To answer your question about handling the responses to matched matrix cases directly on the SCU, yes you can. Each matched matrix case can have a unique 'Next' target. ie if case 0 is matched, go to step 3, if case 1 is matched, go to step 4, if case 2 is matched, go to step 5. Steps 3, 4, and 5 would be the send steps to respond to the device. In the attached example, notice that if case 0,1, or 2 is matched, and that triggers steps 3,4 or 5, I go back to step 0 to see if there is another unsolicited message waiting. This idea of using the matrix to trigger different steps in the sequence works up until you have more than ~ 14 different recieve cases. If you have many different cases, then you will have to use PLC logic to answer the unsolicited messages. To answer your example: .........<h>A:fghdse<t>..................<h>B:klsewq<t>.............. If a receive matrix is set up to look for instances of A:[*.*], B:[*.*] or C:[*.*] it will find the first match A:[*.*]. During this event the host sends data for C. Providing a flush command has NOT been issued am I correct in assuming that the buffer now contains the original data PLUS the NEW data? .........<h>A:fghdse<t>..................<h>B:klsewq<t>.............<h>C:123456<t>..... As soon as the matrix has processed case A, the <h>A:fghdse<t> is removed from the buffer by the SCU. You are left with messages B and C. You do not have to do this manually. Flush is only used to completely clear the receive buffer.

[BITS N BYTES 66]

GREAT RESPONSE!! Your statement "As soon as the matrix has processed case A, the <h>A:fghdse<t> is removed from the buffer by the SCU. You are left with messages B and C. You do not have to do this manually. Flush is only used to completely clear the receive buffer" is a key point that really clarifies how how the SCU handles data. If the matrix case order was B then C then A would string B be removed form the buffer leaving A and C for the next iteration of the matrix? In other words does a matched receive message remove the matched data from the buffer [wherever it resides] leaving all remaining unmatched strings in the buffer for examining by the next issued PMCR command? I'll try out your applications tomorrow and hope all is answered. Once again many, many thanks for your help and advice. By the way, I have hooked up an interface with hyperterminal to test my application - sending and receiving messages OK. Can you recommend a better/more flexible Serial Terminal Emulation software for testing? Edited 4 Oct 2005 by BITS N BYTES

[PMCR 66]

The Matrix Cases will remove the strings from the buffer in the order that they arrived into the buffer, not the order listed in the matrix. The order of the matrix only matters when processing the first string in the buffer. For example: Case 0: <h>+"ABCD" + w(D0,*) + <t> Case 1: <h>+"FGHI" + w(D0,*) + <t> Case 2: <h>+"ABC" + w(D0,*) + <t> Case 0 would receive a string <h>ABCD1234<t> Case 2 would receive a string <h>ABC1234<t> If the cases were written as Case 0: <h>+"ABC" + w(D0,*) + <t> Case 1: <h>+"FGHI" + w(D0,*) + <t> Case 2: <h>+"ABCD" + w(D0,*) + <t> then Case 0 would receive both <h>ABCD1234<t> and <h>ABC1234<t>. Granted, this is usually only the case when the '*' is used for the length. As far as a terminal emulator, I use one that I wrote. It is available from the download section of this forum, under the More Misc Downloads, Tutorials, and Guides section.

[BITS N BYTES 66]

Tested applications today and found your ideas and suggestions worked well. The confusing issue in the matrix cases is that a GO TO # for a matched case goes to the STEP in the routine that calls the matrix, it does NOT move within the matrix cases. Not explained at all clearly in the OMRON documentation. Now to some hopefuly final questions regarding matrices. If the last case in the matrix [15] is set as END does this end just the MATRIX lookup or does it end the complete protocol that called the matrix? If the last case is set as GO TO step # does the matrix end but return to the step defined in the GO TO statement? I ask this question to see whether it is possible to have more than one matrix lookup within a single protocol. This would allow more than the 15 matrix cases to be processed with a single protocol. In other words first step in protocol calls MATRIX A. If any strings are matched in any of the cases within MATRIX A the desired response is carried out. At the completion of MATRIX A a GO TO step is used to call a step in the protocol that starts a new MATRIX B seach. I have run a simple test to try this method, but cannot get it to work. It appears that a matrix case pointer from the first MATRIX A call is being used in the SCU. If I have 4 cases in MATRIX A and 8 in MATRIX B, MATRIX B misses its cases 0 thr 4 and starts at case 4. Is there any method to reset the matrix pointer so that after MATRIX A is complete MATRIX B will start at its own case 0? I have attached a test application:- The SINGLE MATRIX TEST reads the serial buffer for messages A,B,C or D and responds with A REPLY, B REPLY, C REPLY, D REPLY. Any other string returns BAD MESSAGE. The DOUBLE MATRIX TEST looks for a match A,B,C,D in the first matrix and E,F,G,H or any othe character in the second matix. The SINGLE MATRIX TEST works fine. I cannot get the DOUBLE MATIX TEST to function!! MATRIX_TESTS.psw Edited 5 Oct 2005 by BITS N BYTES

[PMCR 66]

You are correct, the matched case 'next' column goes to a step in the sequence that called the matrix. When the last case has the 'next' column set for 'end', then the entire sequence ends, not just the matrix. I see exactly what you are trying to do in your example. Here is the wrinkle. Because the matrix identified that you had data that matched the model of <STX> ..... <ETX>, it flushed the first message when the first matrix got to the 'Other' case. If this did not happen, most applications would end up with junk data in the beginning of the buffer forever. In my experience, any time you have more than 15 cases, you have to pass it to the PLC and let it formulate the response.

[BITS N BYTES 66]

PMCR I found the same issue through further testing. To resolve the problem I think it will be necessary to have a two character header for each matched receive message. Both macros look for a match using the second character of the header as the <h> in the message structure. The first character of the header is specified as a match in the last "Other" case and points to the start of the second macro. The second macro uses the second character as the header for each of its cases. Using this method the case that switches to the second macro call does not strip data from the receive buffer that needs examining by the second matrix. I'll try this method tomorrow and post results.