CX-Protocol

[Andy_P 7]

Currently I have an extremely basic grasp of protocol macros and their use. I have just about got to grips with using some from the 'ASCII Generic' file located on this site. Digging a little deeper, I would like to understand the entries 'Address' and 'Length' when it comes to constructing a send or receive message. Reading the manual, it appears that 'Address' is only required when using a multi-drop connection and the unit number of the connected device is required. Is this a correct assumption? If so, does this mean that for single drop, RS232 connections, the 'Address' entry is never required? The 'Length' entry appears to truncate a received message to this length (bytes or words?) if it is greater than this value. Once again, is this a correct assumption? As for transmitted messages, I'm not too sure how this works! Any help with these queries would be grealty appreciated. Just by scratching the surface, It appears to me that protocol macros are extremely powerful, so I would like to learn more about them. Andy.

[Jay Anthony 118]

Again it depends on how you use the length field. Message length is typically used for protocols that do not have terminators (Modbus as an example). Some protocols(again Modbus) have a length field. Instead of you counting it up, you let CX protocol do it for you. The Length indicates how much data is in the message so the receiving device knows when the message has ended. Allows for calculating the length of the command Expressed as either 1 or 2 bytes in BIN or ASCII Default length can be initialized 1 Byte Default 0-255 2 Byte Default 0-65535 BIN gives the hex ascii code for the length ie <17> for a message of 23 bytes. (This is correct) ASCII gives the BCD value for the length ie ’23’ for a message of 23 bytes. The Default is a starting point for the length calculation. Also know as a ‘Seed’. Length Selection Allows for setting the starting and ending data elements for length calculation in the message. Indicated by red text. Each piece of the string with a ‘+’ between is an ‘Data Element’. The <h> is data element 1. The <t> is data element 7. Notice the Length starting and ending ‘data element’ position. The Length Measurement is taken from data element 4 to 6. They are in Red.

[BobB 58]

If you are using the CJ1, you can use the $LEN function to calculte the length of the string for use. I use it all the time for SMS messaging. Function 650.

[Sleepy Wombat 27]

Yep .....Use a wild card, * , for the length option and the recived message will not be truncated....

[Andy_P 7]

Thankyou for your replies. They have answered many of my questions. The 'Address' entry now makes sense. Case closed! The 'Length' entry.... Could you please clarify my assumptions, below. For transmitted messages: A value is calculated by the protocol and inserted into the string at the required position, in either binary or ASCII format. For received messages: A value is already present in the string indicating the length. It is not calculated by the protocol. If a string has, for example 20 characters, but the length character indicated 10, then the entire message would be received, but only 10 characters would be transferred to the PLC. Thanks for your patience! Andy.

[Jay Anthony 118]

Although it is true that if you are selecting every field in the receive message as the range for length to calculate, the message will be truncated if received characters or greater than length characters, this is not the intended use of length in a receive message. The concept of the received message is to provide for a placeholder for every field in the received string. This is known as match strings. Match strings can be literal (constants, both binary or ASCII), calculated field (like length and checksum) and variables (those characters which are sent to the memory map of the PLC, sometimes known as paydirt.) For a receive message to be valid, you must provide for matching every character which is received, not only the various types of fields but the order in which they are received.

[Andy_P 7]

Thanks Jay, this makes much more sense now. All I have to do now is learn the remaining 99% of protocol macros and I might be getting somewhere.... Andy.

[Jay Anthony 118]

You will proably learn best by looking at other Protocol Macros. What serial devices are you looking to communicate with?

[Andy_P 7]

Currently using PMCR to transmit a very basic string with no reply to a PC, reading data from a Microscan barcode reader (MS-3 and MS-911), and also receiving a very basic string from a machine built by my company. I am only using PMCR because it was forced upon me, although it may prove to be a blessing in disguise. Now that I understand the terminology and construction of protocols a bit more, I have been able to look at the system protocols with a bit more understanding. My current level of knowledge is adequate for my present applications, but I always like to try and stay a step ahead for any future problems that may arise. At least I know enough now to have a play around and have a fighting chance of working out what is going on. Thanks, in no small part to the help received from this board. Nothing worse than trying to learn something new and complicated when you have deadlines to meet. Andy.

[Jay Anthony 118]

Great attitude! Sign of a good programmer! ASCII Generic Protocols should work for your present applications. If you get into something more complicated, let us know!