MSG Reads vs. Write

Just for my own sake, wouldn't it be easier and make more sense for Target PLC's to do a message read and not have the Master do a write? That way scheduling becomes less hassle. I've always found it easier to debug (especially for persons unfamiliar with the systems) to see a message read instruction instead of watching the target data tables value change and not finding where the values are coming from. I see a lot of MSG instruction questions on the forum and it seems most are trying to Write values out and it just got me thinking about how I have never really used the Write MSG instruction, only reads. I guess it's more of a philosophical and techique question more than anything else. Just wondering what opinions others have on the board here.
In general I'm referring to AB Logix5 and Logix500 affected controllers.

Traffic regulation on any network is not a simple task. If you want thrue deterministic control then you must have a mean of getting a traffic cop into your system.

Master/Slave is but one way to do it.

And of course every brand has the best way

If you where to develop a "standard" then you would be the newest best.

Now i use mostly Logix5000 processors and use the ENBT ethernet cards for deteriministic produce/consume. That way the ethernet cards and processors handle the traffic and give feedback if communication fails. I've found this as the easiest and best way to pass information between processors.

Originally posteb by LJBMatt:
...and use the ENBT ethernet cards for deteriministic produce/consume.

Click to expand...

Don't get people here started. Technically, Ehternet/IP is not deterministic. Many will tell you that to the exclusion of all else. It doesn't have a mechanism to guarantee a given communication timeslice to specific nodes. It just uses raw speed to provide data update rates that make it appear deterministic. The only issue you may see is jitter due to inconsistent update times.

I tend to agree with you about the read versus write. It is easier to sort out data transfers with reads. Which method is better in terms of communication channel utilization depends on whether the base data changes more often or if the need for the data occurs more often. For example, if I need to know what the level in a tank is once every 30 seconds but the level changes every second, I have fewer communications if I read the data. However, in the same example, if the level only changes once every five minutes a write will use less communication time.

Keith

Your initial inquiry was about a SLC 5/03, so I assumed that you were using serial communications. I have found it easier to de-bug using all communications controlled by the master with reads and writes.

Etherenet is an entirely different problem, and in the ControlLogix series all of the overhead and so forth is taken care of in setting up your data blocks.

If you are using MSG instructions in PLC-5s, SLC-500 and CLGX systems, it makes sense to always have the subordinate PLC do a READ request from the PLC it needs data from and then use the various bits for communications (ER, DN etc..) to decide if you got the data ok and then move it to the registers that need it. This works depending on the architecture and control system philosophy that has been chosen. I would not recommend having a master PLC do writes out to specific PLCs. This seems like a blind approach. Instead have the PLC needing data from a PLC read it and use logic to determine that all is well.

I have a SLC504 going to a PLC5 (DH+). When the SLC has a fault, I trigger a Message Write to the PLC5. It is only triggered on a fault. If I had used a Message Read, then it would have to be in the PLC5 and I would have to constanstly do a Read to see if there is a fault. On a small network, this would not be a problem

Our network has a dozen SLC's, 1 PLC5, 6 PanelViews, 3 HMI's. We have problems with speed due to all of the processors and message blocks. What we do is when we have message write is only trigger them on a change of state.

First, you need a watchdog programmed into your message logic. The DN and ER bits are OK but they don't tell the whole story. You need some verification that your message write got through or your read got live data.

All reads, all writes, read/write from a central PLC... They all have their place and it depends on your system. You can make any of them reliable. All of them require careful documentation. Many people will claim that one system is more intuitive than the other, but they don't seem to agree on which one that is. <g>

One flaw that gets overlooked a lot is: Messages succeed just fine on a target processor in program mode. The data read is probably worthless or the action requested isn't going to happen, but you will get no errors on the message. A watchdog will cover this.

Another big area of contention: Triggered messages vs. scheduled messages. True, triggered messages can reduce your average network load. However, they make it very difficult to predict if you are at risk for overloading the network if a lot of triggers go off at the same time. Scheduled messages may take more bandwidth on average, but the load is constant and the time it takes a message to get through is pretty consistant as well. Basically, if you don't have the bandwidth for your message traffic, triggering doesn't really solve the problem. It may mask it and make it virtually impossible to troubleshoot though. Can you tell I prefer scheduled messages?

For a network like Mark described, the first thing I would do is segregate the Panelviews and HMIs from the PLC-to-PLC comms. If you want reliable messqage traffic, don't share a network with those bandwidth hogs. It's very common and quite natural for networks to be added to until they barely work, that doesn't mean it's a good idea.

For a network like Mark described, the first thing I would do is segregate the Panelviews and HMIs from the PLC-to-PLC comms. If you want reliable messqage traffic, don't share a network with those bandwidth hogs. It's very common and quite natural for networks to be added to until they barely work, that doesn't mean it's a good idea.

Mellis,

How would you segregate the Panelviews and HMIs from the PLC's? Maybe I am not seeing something. We have one blue hose DH+ linking everything. It is a long production line and info needs to be passed back and forth.

Steps are being looked at to alleviate the problem like maybe upping the baud rate to 230K. The PLC5 also will soon be upgraded to ControlLogix platform.

Mark,

It depends on the system, but in a lot of cases I've seen the Panelviews each need to talk to just one PLC while the PLCs need to talk to each other. For SLCs this means you can move the Panelviews to the serial port and get them off the DH+ (not a cheap solution if you already have the Panelviews). For PLC5-40 and up you have more than one DH+ port. I tend to use 1A for programming access and PLC-to-PLC comms and 2A for Panelviews or HMIs. Bascially one DH+ is plantwide and one is local.

I've seen several SLC networks that evolved from separate SLCs each with one or more panelviews that were joined together to provide programming access. This resulted in a network clogged with Panelview traffic.

Having a ControlLogix in the system offers some opportunities to re-organize your network. You can break up your DH+ network into serveral segments that get bridged together at the ControlLogix backplane with multiple DHRIO modules. You can do this with or without a ControlLogix processor in the rack.

A few thoughts on the matter:

I once did some work in a plant where MSG Writes were absolutely forbidden. It turns out all the PLC-5E's were connected by routers to the corporate WAN. Somebody once put in an incorrect IP address in a MSG Write in a PLC-5E in Arkansas that ended up writing to the controller I was working on in Texas. The net effect was that I had sixty tons of steel moving towards me and not obeying the STOP button. I've never been so glad for properly placed pull-cords in my life.

I like report-by-exception messaging because it saves on bandwidth, but of course you have to do some design and modelling to account for simultaneous or repeated events. This is especially true if you're using DH+, DH485 or a DF1 serial network.

Logix modular networking makes so much of this stuff moot by reserving bandwidth and making connection, status, and recovery all handled by firmware instead of your application code.