Studio 5000 Produced/Consumed Implicit vs MSG Instruction Explicit
Implicit vs Explicit Messaging in Studio 5000: Which one is “better”?
Bradley Bick put out a post about implicit and explicit messaging and asked if I was teaching it the right way. Coincidentally I built this trainer the other week for someone who needed to get in the weeds of just that.
Quick definition of terms. Implicit is the Produced/Consumed tags that we use to exchange data with PLCs that are set up in our IO Configuration. Explicit is when we use MSG message instructions to exchange data...yes there is more to it but...
The right way is a really gray term. If you were to ask Josh Varghese with Traceroute if we should use implicit messaging, I’m sure he would ask if we really need those packets flying around every 20 milliseconds, how often is the data changing, and why on earth didn’t someone check that Unicast box?!? If you were to ask someone troubleshooting a machine, they are likely to tell you that even if a response time of 20 seconds is acceptable, that 20 millisecond RPI is perfectly fine :) The answer is probably both.
A little more about Implicit Messaging. This is how most of the items in your Studio 5000 IO Configuration communicate. Once set up, it will send and receive data to these devices in a predictable, repeating basis determined by the Requested Packet Interval (RPI) and we will know the moment that there is an issue with the communications.. Once set up, there is no additional code needed to make this work.
A little more about Explicit Messaging. Explicit message requires that you set up messaging instructions to read or write the data to the other device and you must enable the message each time you want to store or retrieve that data. Typically it will have access to additional data that is not accessible with explicit messaging. A good example is I can put a Powerflex 525 in my IO Configuration and control it, see that it is running, and at what speed. But using explicit messaging, I can get it DC bus voltage, motor voltage, motor amps, kilowatt hours, etc.
Which one is better? Like every tool, they both have their pros and cons...
Troubleshooting. Since I mainly do training on troubleshooting PLC controlled machines, I have to lead off with this. I always stress to look at the LEDs when you walk up to a machine. There is no clearer indication of a problem than the IO light flashing at you which is based on implicit messaging. In Studio 5000 you will also see this indicator at the top, and in the IO Configuration you will see the little microscopic yellow triangle by the device at fault, which is also based on implicit messaging. Diagnostics can be added to the explicit messaging of the MSG instruction but in 99% of applications, the programmer does not. Implicit for the win.
Connections. There is nothing more irritating than seeing a PLC that is maxed out on its IO connections and has a device in the IO Configuration that isn't being used for IO. Implicit connections are limited because it has to make sure it can reliably send and receive the data. There are usually limits on the number of concurrent explicit connections but since they are not always open, you can stagger your messages and in theory have infinite connections. Explicit for the win.
Cross Referencing Tags. When chasing down a problem, the cross reference is your ultimate friend. Usually, we are “chasing the Ys in the Destructive column”. When you get to a consumed (implicit) tag, you will not have any Ys but your base tag will show the other PLC and the tag name in it. If using a read message (explicit) then you will have a Y that leads you to the MSG instruction. But what if the other PLC is using a write message (explicit)? It will appear that nothing is writing to that tag. We have a fun exercise in class to chase that one down during a training week. Implicit for the win.
Adding Online. Produced and Consumed tags (implicit) can only be added offline and then downloaded to the PLC so you must schedule downtime to do this. MSG message instructions (explicit) can be added while the PLC is in RUN mode and production is running. Explicit for the win.
Can’t we have both? I believe a mix of both is the best compromise. It is hard to beat the troubleshooting advantage of the IO LED on the front of the PLC, but the default RPI is 20 milliseconds? That can be slowed down a lot. And do we need to exchange 100 bytes of data or will one by do and then send the rest over an explicit message?
Also, every connection, whether implicit or explicit, should have diagnostics written in the program BEFORE we have a connection problem. We can write code to see the IO LED and the yellow triangles in the IO Configuration, then count each occurrence. You can do something similar with your message ER bit and even grab the error codes.
Here is an example of setting up an implicit Produced/Consumed tag.
Here is an example of setting up an explicit MSG Message Instruction.