RS 5000 messaging

toddp65

Member
Join Date
Aug 2014
Location
Florence, Ky
Posts
280
So I have an input on a conveyor line that I wish to control an action on another plc that is on the same network but as of now there is no messaging to and from between the processors.
I'd like the input to control an action on the processor as well as. Right now the input is converted to dint in the resident PLC. Is it possible to take this same input, convert it to another dint and msg to the other plc?
Both controllers are CLX, one a L32 E the other a L30.



Thanks!
 
Great.

The purpose of the prox currently starts the infeed conveyors previous to it once the line begins filling up with cans from the filling machine. It currents resides in the PLC for the transport conveyors.

I want to use the same input the can filling machine along with a timer to shut down the filler if it sees a can for x amount of seconds thus indicating a backup on the conveyor line.

So without reading the AB PDF yet, I'm assuming I may or may not have to add the consumed PLC to the network tree but also must convert the binary to a DINT to be moved or msg'ed to the other PLC after configuring the MSG instruction with IP address and such. Does the message travel to an arrry or tag in the consumed PLC?


thanks!
 
A brief summary of how it works:

In the Producing controller, you will move the state of the prox switch input bit to a DINT tag, which you will designate as a "Produced" tag. This must be done offline.

I strongly prefer to set up a DINT[x] array tag. The overhead is negligible and the usefulness of more data is high.

In the Consuming controller, you will put the Producing Controller in the I/O tree.

In the Consuming controller, you will configure a DINT or DINT[x] array and define it as a "Consumed" type tag. When you do so, the Tag Properties window will prompt you to select the Producing controller from the I/O tree, select a periodic rate, and give the exact name of the Produced tag.

The Produced Tag and the Consumed Tag must have the exact same data type and you must specify the exact name of the Produced Tag when you configure the Consumed Tag. Any differences in spelling or data type will cause the connection to fail.
 
So use a DINTx if there are going to be multiple messages or a DINT if it's just singular.

So receiving the consumed tag I am able to reference that tag in the filler program to incorporate it into a rung that would eventually stop the machine.
I supposed I can convert it in the logic to perform that particular task.

Thanks again
 
I like to create a DINT[x] array tag of ten elements or so, just in case I need them later.

Maybe I decide I want a watchdog, or the conveyor speed, or the safety circuit status.... make the data ready even if you don't need it later.

In the Consuming controller, I like to make a Consumed Data Processing routine that interprets the Consumed tag and breaks out its bits and words into internal descriptively-named bits and words in the Consuming Controller.

So you'd have a rung that did something like

Consumed_Data[0].1 PLC2_Conveyor_Prox
--------] [---------------------------------( )------
 
Here's another way ....


If both PLCs are Logix5000, and on the same network, you can "share" the input module that hosts the Prox between the two processors.


Just make sure the configurations of the module are the same, and add the module to the I/O configuration of the other PLC. Copy/Paste does this for you.
 
A Listen-Only Input connection is a great way to do this with 1756 ControlLogix, but the CompactLogix doesn't support that sort of bridged connection on its I/O bus.

The whole Input module image could be Produced, but it's probably simpler to just make an array of DINTS and Produce/Consume them.
 
A Listen-Only Input connection is a great way to do this with 1756 ControlLogix, but the CompactLogix doesn't support that sort of bridged connection on its I/O bus.

The whole Input module image could be Produced, but it's probably simpler to just make an array of DINTS and Produce/Consume them.


I would never advocate a "Listen-Only" connection, because without additional logic, you don't know if the producer has gone AWOL.
Having said that, you would need additional logic in a "full share" scenario, so I agree that a Produced/Consumed tag would be the way to go, especially if it included "CONNECTION_STATUS", to indicate the validity of the consumed data.
 
The producer consumer tag thing can be very responsive if you set it up with change of state. You then use a IOT on the produced tag to force it to update on the target system. That way you can have fast response without hammering the connection.
 
I like to create a DINT[x] array tag of ten elements or so, just in case I need them later.

Maybe I decide I want a watchdog, or the conveyor speed, or the safety circuit status.... make the data ready even if you don't need it later.

In the Consuming controller, I like to make a Consumed Data Processing routine that interprets the Consumed tag and breaks out its bits and words into internal descriptively-named bits and words in the Consuming Controller.

So you'd have a rung that did something like

Consumed_Data[0].1 PLC2_Conveyor_Prox
--------] [---------------------------------( )------

and how would you do a routine to transfer over the actual conveyor prox from the producer?
Local Machine DINT

---[local:1.I.01]--------------------------( )
I
I------(Produced DINT)
 
The IOT Geoff is referring to is the IOT (Immediate OuTput) instruction in a Logix processor, not "Internet of Things"


To map your prox, you just map it into one of the bits of a DINT. Let's say you're going to produce 10 DINT's, with one of them being reserved for Boolean data like your prox signal, and the other 9 being reserved for integer data. You might create a tag called "Produced_Data" of data type DINT[10]. This creates an array of 10 DINT's, called Produced_Data[0] through Produced_Data[9]. Let's use Produced_Data[0] for your Boolean data, and 1 through 9 for your integer data.



Map the data something like this:
Code:
|    Prox_Input              Produced_Data[0].0
|-------| |--------------------------(  )----|
|
| Some_Other_Signal          Produced_Data[0].1
|-------| |--------------------------(  )----|
|
| Singularity_Imminent       Produced_Data[0].2
|-------| |--------------------------(  )----|
|
| Produced_Data[0].3         Produced_Data[0].3
|-------| |--------------------------(  )----|
|
...and so on. You'll note that with the last (spare) bit, I mapped it into itself. This is just a personal preference thing - basically, it just means that it won't every do anything, but if I did want to toggle it on and off for e.g. diagnostic purposes to watch it change in the other PLC, it's easy to do. Also avoids using AFI's which I prefer.


With your remaining DINT's, I again prefer to map them into themselves - i.e. just put 9 MOV instructions on the subsequent rung, with the source and destination the same in each case. Again, it just means you can see and manipulate the data easily for diagnostic purposes, and means that later on when you want to map some additional data, your code structure is already in place and all you have to do is change the input to your MOV instruction.
 

Similar Topics

I have a bit of an odd situation. I'm having trouble sending ASCII commands over an open TCP socket. The problem is that I have a device that my...
Replies
9
Views
3,427
Is it possible to add 1747-L541C to RS5000 so I can use message to get some float values? I am using 1761-ENI/D for Ethernet conversion on the...
Replies
15
Views
8,945
Just wondering what is the best practice on setting up paths for messaging between controllers. Is it better to add the controller I'm messaging...
Replies
3
Views
1,916
I have a MSG block poling an encoder for a velocity value. Previously I had a timer setup with a one shot followed by the MSG block to get...
Replies
6
Views
6,923
Hi, We're upgrading a plc5 to control logix and are using a dhrio card to communicate with the DH+ network... but I can't figure out the...
Replies
2
Views
1,500
Back
Top Bottom