SCU21

[frank.raymond 0]

I will have data coming to a port on a SCU21 that is more than 255 bytes which I have no control over. The data I need is in the first 10 bytes or so and the terminating characters are <CRLF> hence I have the port ending character set the same. My question is after I receive the data that I need the data will continue to come and eventually give me what I believe will be an overrun or overflow. Assuming the over something does occurs how can I clear this useless data from the buffer to prepare for the next cycle of data that will again be in the first 10 bytes or so. Can I disable the buffer after I receive the useless data? Can I reset only the port to clear the buffer? Do I have to reset the module (I am trying to avoid this since I will have a barcode scanner connected to the other port that may be in use while reseting the module thus lost data). Any thoughts? I'm using No Protocol. Thanks in advance

[BITS N BYTES 66]

I would suggest you use Protocol Macro mode vs No Protocol. With this method you can read only the valid data in the receive buffer and ignore all other incoming data. Does your application have a start code as well as the <CR><LF> terminator? If yes then the MATRIX search application in Protocol Mode is the best approach. It can be setup to recognize only data between start code and terminator, all other data is flushed from the buffer. Post some more details and we can help you further. I have done quite complex applications with Protocol Macros so am pretty familiar with their application.

[frank.raymond 0]

I believe I can have a start code added however I would prefer to keep it no protocol.I don't disagree about the powers of PMCR.

[BITS N BYTES 66]

Why? the whole idea of Protocol Mode is to make the system more intuitive resulting in less PLC code. Think of the SCU running Protocol Macros as a slave communications co-processor to the master PLC. Implemented correctly it is a powerful and predictable system that will manages serial communications in parallel with standard PLC code. Load your communication code into the SCU with Protocol macros and let IT do the bulk of communications tasks for you. You sound overly skeptical! Afraid/unsure of how to use PMCR's? Don't be, we are here to help.

[frank.raymond 0]

You sound overly skeptical! Afraid/unsure of how to use PMCR's? Don't be, we are here to help. More so unsure. Since you're offering support, I'll take advantage of your hospitality. I know that the data I am looking for comes in two seperate records. The sequence is as follows from the PLC perspective: 1) Xmits 123456<CR/LF> 2) Rcvs 1st record of 7 alpha/numeric characters with a <CR/LF> 3) Xmits a response of XXXXXX,P or XXXXXXX,F 3) Rcvs 2nd record of 255 + charcters. The data that I want is at the beginning of the record, begings with a capital T, has a length of 13 bytes consisting of both alpha/numeric characters, and ends with a <CR/LF>. The remaining record exceeds 255 bytes and is also alpha/numeric characters. Approximately 60 seconds later the process begins again. Protocol of 9600,N,8,1. Need any more info please let me know. I'm ready to learn... Thanks, frank Edited 7 Jul 2010 by frank.raymond

[BITS N BYTES 66]

What is model # of PLC are you using?

[BITS N BYTES 66]

Well here's a start to wet your appetite all examples use Read/Write from/to DM areas in PLC:- 3 Protocol macro Send/Receive sequences 000,001 & 002. 000 TX_RX_Step1 TX "12345<CR><LF>" RX Read 7 bytes of data in buffer prior to <CR><LF> and move to PLC starting at DM 00000. 001 TX_RX_Step2,P TX Read 6 bytes of data starting at DM00010 in PLC and transmit this followed by ",P" and "<CR><LF>". RX Read 13 bytes of data in buffer between T prior to <CR><LF> and move to PLC starting at DM00030. 002 TX_RX_Step2,F TX Read 6 bytes of data starting at DM00020 in PLC and transmit this followed by ",F" and "<CR><LF>". RX Read 13 bytes of data in buffer between T and <CR><LF> and move to PLC starting at DM00040. Note communication port1 settings in N/A [0] are set for Protocol Macro mode and 9600,N,8,1. Attached file is a CX-One Protocol Macro file. Change Extension from ".bmp" to ".psw" to read with CX Protocol application. FranksStuff_.bmp

[PMCR 66]

I think that Bits and Bytes is giving sound advice as usual. This is a perfect PMCR application, and Bits and Bytes is a top notch PMCR programmer. The receive buffer when using a PMCR can be set as high as 1000 bytes, vs 255 when using No Protocol mode. New products: There are also some new SCU modules available (CJ1W-SCU22, 32, 42) that when used in conjunction with a CJ2M or CJ2H can achieve higher throughput in No Protocol mode. There are new DRXDU (Direct Receive Unit) and DTXDU (Direct Transmit Unit) instructions that execute immediately in scan when using a CJ2M or CJ2H. Edited 7 Jul 2010 by PMCR

[frank.raymond 0]

Thanks to both for the info. I am using CJ1M's for these app's. I just finished looking at the file that Bit 'n Bytes sent. I will be connecting to my development box and start learning a bit (no pun intended) about PMCR's.

[Yair 2]

I think you can keep using the RXDU and add an other RXDU instruction with #00 for the number of bytes IN ORDER TO CLEAR THE BUFFER/ If 0 is specified for N, the Reception Completed Flag and Reception Overflow Flag will be turned OFF, the Reception Counter will be cleared to 0, and nothing will be stored in memory.

[frank.raymond 0]

Yair, This is an intersting approach. I will try this. Is there a way to determine if data is in the buffer before the end character is received? thanx, frank

[Yair 2]

Reception counter (n+10 for port 1) (n+20 for port 2) (n=1500*unit No.) Indicate the number of bytes received. (waiting in the SCU buffer).