mjrx

ML 1200 and radio modem problem

30 posts in this topic

I think the problem I experienced with serial port malfunctions three years ago were confined to the Integra TR models. Everything looked perfect on the over-the-air diagnostics, but we were able to observe malfunctions of the serial port in which partial or complete bytes were simply not transmitted to the PLC by the radio. These "missing bytes" were just flat "mark" state (data 1) in the serial data stream; they were not necessarily at the end of the packet so we didn't have any different results with DOX or without. I recommend implementing the remediation steps I outlined: consolidate the data into a single block and add a buffer clear for overflow conditions. If that does't get you acceptable performance, you're going to have to get deeper in with serial analyzers.

Share this post


Link to post
Share on other sites
Thanks very much for your help on this. I've learned more about the DF1 protocol than I ever dreamed. I have implemented your suggestions. Question on DF1, I am trying to decipher my data stream - I have a DF1 manual (older) but I am stuck on a few things. I have figured out the basic packet structure, but how in the packet data stream do I tell what type of data (B3, B9, N7, T4), the number of words (or bytes), and the starting address of that data that is being requested?

Share this post


Link to post
Share on other sites
Disregard the previous post - I have figured it out, it is FNC code followed by size, file #, type, starting element. Thanks.

Share this post


Link to post
Share on other sites
Decoding DF1 by hand is time-consuming but possible. I spent an hour kicking myself around the room the first time I saw FTE NetDecoder do it automatically. But here's an example, from previously: 10 01 04 10 02 04 01 0F 00 C0 03 A2 14 15 89 00 00 10 03 33 C2 Skip down to "A2", which is the SLC-500 style Read Data Table command, properly called a "Protected Typed Logical Read with Three Address Fields". By "Typed", it means that the Data Type (B, N, F, etc) is explicitly part of the command. You'll find the details on page 7-17 of the 1770-RM516 protocol manual. This command is "Read Data file N21, Starting at Element 0, length 10 words" (above, I mis-typed 4 words). 0x14 indicates the total data being requested is 20 bytes. 10 Words x 16 bits each = 20 Bytes. 0x15 is Data File 21 0x89 means Integer Data File 0x00 means starting at data file element zero. 0x00 means no sub-element is being read. I always skim the protocol strings looking for A1 and A2, the most common SLC function codes, and for 89 and 85, which indicate Integer or Binary data files, then orient myself from there.

Share this post


Link to post
Share on other sites
See Rockwell Technote Answer ID 33871 Issue: Customer was seeing the "Lack of Memory" status bit being set in Channel 1 Channel Status in a MicroLogix 1500 LRP processor. CH1 was configured for DF1 Half-Duplex Slave. Tried different baud rates, as well as the Comms and Message Servicing Selection bits. Nothing seemed to clear this bit. Details on "Lack of Memory" status: The MicroLogix 1500 slave can buffer up replies for up to 12 master commands. Once it has 12 replies buffered up, the slave will increment the "Lack of Memory" counter with each additional master command received. The receive buffer gets cleared one at a time with each successful master poll. Therefore, this counter is an indication that communications is stronger from the master to the slave than it is from the slave to the master. If the slave can receive the master's commands, but the master can't receive the slave's acknowledgements or replies, then the replies can eventually fill up in the slave's buffer. Note that this is more likely to happen if the master retries is set to zero and the slave's retries is set to one or higher. As long as the master retries is set to one or higher, any time the master transmits a command that doesn't get acknowledged, it will send a poll packet before retrying the packet. That way, even if the slave's buffers are full, when communications is working again and the master sends a new command and doesn't receive an acknowledge, the master will send a poll packet, which will allow the slave to transmit the first reply in its buffer. After acknowledging that reply, the master will retry the command, which the slave can now receive and acknowledge, and the master will poll the slave twelve more times until it receives the reply to that last command that it is expecting. Solution: To minimize the slave buffer from filling up, set the master's retries to greater than zero and the slave's retries to zero (with the slave's duplicate detect left checked).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now