Introduction to SLC-500 Messaging
With SLC-500 Messaging, we will transfer the contents of a data file from one processor to another. There are many reasons this might be necessary. For example, if one section of a conveyor shuts down, we might want to tell the upstream conveyor to shut down as well. Also, we can get the status of any other processor on the network, such as speed, mode, or faults.
It’s important to realize that from a troubleshooting point of view, it’s better to read data, than to write data. When the troubleshooter is tracing a bit, they will come across the message instruction, and can trace where the data is coming from. However, from a bandwidth point of view, we might only want to write data to another processor when a change has occurred. Especially on slower networks, such as DH+, we need to always keep the amount of data we transfer in mind.
For this example, we’ll read 5 elements of data from N90:0 at node 10 into N90:0 at Node 11. We are using a 5/04 processor in this example on DH+. The 5/04 at Node 11 will execute the read command at periodic intervals.
Set up the data files in Node 10
In node 10, let’s create data file N90, which is an Integer file. We will need at least 5 elements. To do this, you must be offline. Right click Data files, and create a new Data file.
Keep in mind that we could have chosen any data file. To demonstrate, I’m just creating a new file.
Next, I’ll open the N90 data file and populate this with random data. This will prove that our data transfer is working if we see the same values in the target processor. Your logic will usually populate this data table with meaningful information.
Finally, I’ll download the changes to node 10.
Set up the data files and logic in Node 11
Next, I’ll open the project for Node 11. There are a couple data files we need to create. First, we’ll create N90 in the same manner that we did for Node 10, except the name and description will be a bit different.
Also, I’m going to create another Integer file. This data file will be the control block for the message instruction to operate. This will keep track of the instruction’s status and error conditions. I’m going to create this as integer file 91. Leave the length at 1, because the control block will expand as needed when we write the message instruction.
Writing the logic
At last, we will write the logic in Node 11 for SLC-500 Messaging. Keep in mind that the message instruction will execute one time per rung transition. This means that we need something to trigger the message instruction periodically. I’m going to use a self running timer for this as shown. Keep in mind that you don’t want to use a timer address that is already in use in your project. In this case, T4:7 is available. here is an example of a self running timer that resets itself every second. This will give us a pulse for the message instruction. By using a timer, I can easily control the execution time of the message instruction. Another option is to use bits from the free running clock, or S:4.
Finally, we’ll add the logic for the message instruction. We are reading from a 500CPU on the local network. As I said before, N90:0 is our control block. The control block length will adjust itself according to our path.
Next, let’s take a look at the setup screen. Notice we have 2 frames: One is for “This Controller”, and the other frame is for the target device. In “This Controller”, we are placing data into N90:0, and are reading 5 elements from communication channel 1. Communication channel 1 on a 5/04 is DH+. In the target controller, we are also reading the data from N90:0. In this case, the data file numbers match, but realize they can be different. Be careful of the node #. DH+ is usually identified in Octal. I’m reading from Node 10 Octal, which is 8 in decimal.
Test SLC-500 Messaging
Next, I’m going to download my work to Node 11, and see if the message instruction is working.
We are getting a DN bit, which is good news, so let’s check the data table, N90.
Finally, we see the that we are getting our data!
If you are ready for some SLC to ControlLogix messaging as well, check out this post!
— Ricky Bryce