PLC-5, Max number of MSG enabled at once?

[waterboy 7]

Using a PLC5... I am working on an existing program that has about 50 MSG commands. Some ethernet, some are serial over a radio link. Many are showing Error 37 (Timeout) , 89 (Processor message buffer is full) and one that refuses to ever work shows error 200(Unknown) . In general the communication happens eventually but not as quickly as I would like. I blame most of that on the radio link, However... I see the /EN bit active on several of these MSG at once and I would imagine that this is not optimal or even allowed. The code uses a timer to fire them sequentially in 2 second steps. But since they stay enabled until they either /DN or /ERR, that allows several to be "active" at one time. I saw a sample code here for sequencing through MSG commands using a 16 bit shift register so that further enforces my opinion that only one MSG should be active over a channel at a time. Am I correct about this? If so, what is the proper technique to run through all these MSG blocks without them hammering each other? A larger shift register? If not, what are the limits on MSG blocks comms?

[dmargineau 6]

Sometimes you you get lucky enough to have several MSG commands fire at the same time and get .DN without any .ERs declared; Ethernet comms and lesser data exchanged per MSG instruction could be the successful recipe. However, 50 MSG instructions simultaneously enabled without "logic interlocks" on a PLC5, some using serial over radio are nothing but a major headache! When talking about PLCs/SLCs I think it is a good rule of thumb to sequence the MSG instructions using the same protocol as to only one should be enabled at any time, depending of the .DN bit status of the previously scanned one; prioritizing the ladder logic order depending of the MSG data importance would be the first step; then an unused (let's call it "shift") integer address value could be increased by 1 anytime a MSG gets .DN - comparing the shift integer value (via an EQU ) to 0, 1, 2, 3,...49 would fire up the next MSG instruction in the ladder logic. the last .DN bit should CLR the shift integer address value in order to restart to logic. Of course a faulty link would bring everything to a halt so you might have to decide how long any MSG instruction should be allowed to try to execute; the maximum timing could be incorporated into a TON which could disable the .EN for the stuck MSG and ADD 1 to the shift integer in order to continue the MSG logic.

[waterboy 7]

They don't all fire at the same time, each one has a compare at the beginning to fire the rung at the appointed point in the timer, i.e. 2 secs, 4 secs, etc. but many can become enabled at the same time because they take 30 sec to fail. If that could be shortened this would work better, 30 seconds is such a LONG TIME. And I am concerned about that faulty link... I'll see if I can come up with something to sequence through them, allowing maybe 5 seconds for each serial connection to complete. if it doesn't make it by then it can probably wait til next cycle.

[Ken Roach 194]

Is the Compare function before the rung the only pre-condition on the MSG instruction rung ? Many times I've seen users insert an XIO with the Enable bit after a sequence comparison and end up "fanning the trigger" on the MSG instruction for a second or two, instead of firing the message just once. The method I like for shortening the timeout of a PLC-5 MSG is simply to use a timer that sets the .TO bit of the message control block. This is the only message control bit you're ever supposed to manually control in logic, and it causes an immediate Message Error (/ER) with a Timeout error code. The PLC-5 is really pretty good about buffering messages for the DH+ and Ethernet ports, but serial ports usually don't have the link management built into them that will let you fire a second message while the port is waiting for the reply of the first. I'd have to look up the number of buffers on the Ethernet port of a PLC-5E. It can't hurt to be conservative and just run one message at a time per port.

[Bob A. 1]

I used the serial port on PLC5s to talk to DEC VAX machines with great success. However, the part where the serial port was serviced in the logic was troublesome to develop. This work was begun in 1990, so what I remember is that the key to success is to be very careful to ask the serial port to do only something that it can do successfully. For example, check to see how many characters are in the buffer and read that many (or less). The port can go very fast if it is constrained carefully to do things that it can do. I don't recall doing MSG commands serially, but I would start by trying to sequence them with chrisp logic that did not pile them up in the buffers. Start slow and build up speed and most importantly, have a way to kill anything that fails to proceed to completion. If the port cannot do something, it likely to get "hung". This will then have to be detected and carefully reversed. I have access to the serial port routine that I used, but it is in 6200. If anyone cares, I will take the time to dig it up. To simplify serial communication testing, the old versions of Windows had "terminal.exe" as an ASCII based terminal program. It had 4 groups of 10 Function Keys that could be predefined with serial strings. So you can enter your test data string as a predifined Function Key string and when you click the Function Key on the PC, your data string will come out the serial port. So this is a very useful tool when doing integrations between a PLC and some external device, by making an old PC talk like your device until you get the PLC code working correctly. Having done this for a number of years to get a whole series of testing devices to put their data into the PLC world, I can tell you that it works great, but it requires a committment on the part of the programmer in the development lab. The odds of success in the production arena are not great because iterative testing is likely to be required. All the tools to convert between strings and integers are there and that part works very well. One last suggestion is to build substrings of fixed length and then further assemble them into the final string in a predefined manner so that all strings have the same lenght. Then the Parse going the other way can be predifined in length so that you don't ever loose control of the data. (The best way to solve a problem is to not get it in the first place). I realize this may appear off target, but it could provide an alternative to MSG for moving data over a serial link. Best Regards, Bob A.

[waterboy 7]

There is an ONS after the compare.

[waterboy 7]

These are "Typed Read" and "Typed Write" MSG blocks. I'm not sure I can monitor the buffers in that level of detail. But I do keep hearing the consistent statement of "One at a time" which is what I suspected, so I have to look into making that happen. I should also add that I find that the remote stations can also send data back to this master station at their discretion so that can only compound the problem for the radios providing the link.

[Ken Roach 194]

"I should also add that I find that the remote stations can also send data back to this master station at their discretion so that can only compound the problem for the radios providing the link. " Full Stop. Is the Channel 0 serial port on the PLC-5 configured as a Half-Duplex Master, or in Full-Duplex mode ? In Half-Duplex mode, you can have MSG instructions in the remote devices, and the DF1 Master manages the arbitration and transmission. In Full-Duplex mode, it is very unlikely that you can get away with it because most radios do not have sufficient buffering and over-the-air arbitration abilities.

[waterboy 7]

Channel 0 is System (Point to Point)

[Ken Roach 194]

On the one hand: "Oh dear, what a Charlie Foxtrot." On the other hand: "Wow, I'm amazed this works at all. We should be able to improve the performance and reliability of the system by a lot". Let's talk about the radio modems. What vendor, make, model frequency, etc. are they ? How about the physical connection; just 3 wires (2,3,5) or are the handshaking pins connected ? Let's examine the PLC-5's Channel 0 configuration (handshaking, port speed, etc). This is the kind of system that I specialize in diagnosing and repairing. Often I get into RF meters and protocol analyzers and such, but you can do a lot just by setting up the logic and ports right.

[waterboy 7]

Well thats encouraging... :) Radio is Esteem Model 192C 458 mhz. (Looking at MDS 900 series to get better speeds and be able to program remotely, but gotta fix this issue first, ... then get funding :( ) I would have to look at the pinouts, these have been here for a long time 15 remote sites on radio link. PLC is 5/40E Channel 0 is 19.2k N81 BCC and No handshaking NAK = 3 DF1 ENQ = 3 ACK Timeout = 30 Channel 2 is ethernet used at the location. Edited 31 Aug 2010 by waterboy

[Ken Roach 194]

I'll take back some of my confusion: the Esteem 192 series are unusual among radio modems because they do have a buffering system that is aware of DF1 addressing, so that you can create a "virtual Full duplex" system and use DF1 Point to Point settings on all the controllers. http://www.esteem.com/files/files/FAQAllen-Bradley-192C-S.pdf I have not had direct experience troubleshooting systems that use ESTEEM radios of this type; for reasons I don't understand, ownership of sophisticated radios seems to go hand-in-hand with a refusal to allow hands-on troubleshooting of systems that use those radios. Let's discuss the messaging logic in the remote radios; how is it conditioned ? Does it send data based on a condition (reservoir level, temperature threshold, etc) or on a time basis ?

[waterboy 7]

I hope the newer MDS 900 radios will behave themselves like that. We tried the Esteem Ethernet radios and had very small signal range with them. The Remote sites communicate based on any change in a series of status bits and on a timer. the data sent includes a counter that is always incrementing that acts as a comm fail indication, The master looks for that number to change and if it doesn't change in 600 seconds then a comm failure is indicated. This action of the master reading and writing and the remote sites also reading and writing has me questioning the structure and the chance of collision. the Radio might be able to handle it but perhaps the PLC cant.

[Ken Roach 194]

The controller is capable of simultaneously transmitting a message to one device while receiving a message from another. That's the whole point of DF1 Full Duplex; the controller does not have to wait for a reply from a device in order to process a reply from another device. So I tend to think the PLC is entirely capable of receiving whatever the radio can throw at it. From the perspective of a DF1 Full Duplex serial port, there's no such thing as a "collision". This is where protocol analyzers really shine; you could put Frontline Test Equipment's NetDecoder in between the master PLC-5 and the radio and get all kinds of performance information. If you're in the telemetry business (and with 16 remote sites, I would consider you to be) then NetDecoder might be a very good tool for you. I can't say enough good things about how effective and valuable that software and interceptor hardware is when troubleshooting SCADA networks.

[waterboy 7]

I love any tool that shows how things are working, I'll look at that right after I type this. edit: Ahh, its like wireshark for serial. fairly expensive too for a single project. what about the multiple MSG .EN in this processor? You still feel that there should be only one at a time right? Are you saying that because of the DF1 protocol i dont have to worry about the remote sites when they decide to send thier data without regard to what the master is doing? Edited 1 Sep 2010 by waterboy