MSG

[lccllc 0]

I am having a problem with the message instuction. I have two messages that need to be set off and on to keep a fast update of data from one plc to another one. The problem is triggering the two messages so the are constantly reading data and writing data. I have used them in the slc's with no problem, but for some reason in the control logix I cann't get it to work. I looked in the common procedure manual for Control logix on the messaging instruction and set up the logix how they have it for multi message management and it still does not work. The bits for the message active become true on bolth MSG's but not data transfer. On one mSG the dn bit is set and on the other one the dn bit and the enable bit are set, as the togle ctive bits become true and then go false. If someone could explain a better way of doing this I would be greatful.

[BobLfoot 301]

If i understand you correctly you have a block of data in PLC1 which you want to constantly transfer to PLC2 and vice versa. Your plan is something like doing this with a MSG Read in PLC1 of PLC2 and then a MSG Write from PLC1 to PLC2. You've used this logic before in the SLC Family and it has worked with success. You're trying it between two ControlLogix and this is not working. I suspect the problem lies in the architectural differences between the two platforms. The SLC cues the message when it is encountered in the ladder logic and then executes or operates on the actual messaging activity in the between scan overhead portion of the total scan. The CLGX Ladder CPU sends the MSG Data to the Comm Card {ENBT, DHRIO, CNB, DNB} and turns the MSG DN bit on when the Comm Card has the message request. The comm card then asynchronously sends the data in it's own time frame independent of the Ladder scan. I'm out of time right now, but I'll post a suggested scheme later tonight for you, if workload permits.

[b_carlton 61]

I too await the added information from BobLfoot. Many times the program cannot even BEGIN forming the next message until the previous message is absolutely and totally finished. For example, the 'write' message may depend on the information received by the previous 'read' message. Thus the messaging logic can only continue when some flag indicated that the previous message transaction is totally complete and the information of a previous read is done and in memory. Similarly, a 'read' may have to wait until a previous 'write' has been completely sent. The remote would probably have time to act upon any such information such that it will affect the next 'read'. The queuing action should have a way to be turned off and bits available to indicate the 'total completion' state (if nothing else an indication that the message queue is empty) has been achieved.

[lccllc 0]

Yes Bob that is correct, always a big help you are. Mr. b_carlton I also tried the method of using the .DN in each of the MAG rungs to insure that the two were not trying to send or read data at the same time, much like the BTW and BTR instructions in the SLC PLC's, and still no luck. I was also thinking that if there was a way to read the Data from plc 2 at the start of the scan and send the data to plc2 at the end of the scan this would work to, but I can't think of a way to do this.

[BobLfoot 301]

Ideally I'd suggest you use a read in each PLC and no writes, but you have your reasons for not doing this, so lets try the following: Here is what I am thinking, but cannot test for lack of hardware. PLC 1 has three tags as follows: Data_From_PLC2 DINT[32] Data_To_PLC2 DINT[32] MessagingStepPointer DINT PLC 2 has two tags as follows: Data_From_PLC1 DINT[32] Data_To_PLC1 DINT[32] On First Scan PLC 1 loads the following: Data_From_PLC2[31] = 1 Data_To_PLC2[31] = 1 On First Scan PLC 2 loads the following: Data_From_PLC1[31] = 2 Data_To_PLC1[31] = 2 As soon as it is not first scan in PLC 1 turn the bit MessagingStepPointer.0 true When MessagingStepPointer.0 is true enable the MSG Write sending PLC1-Data_To_PLC2 to PLC2-Data_From_PLC1 When MessagingStepPointer.0 is true the MSG Write is Done Turn off MessagingStepPointer.0 and turn on MessagingStepPointer.1 When MessagingStepPointer.1 is true enable the MSG Read bringing PLC2-Data_To_PLC1 into PLC1-Data_From_PLC2 When MessagingStepPointer.1 is true the MSG Read is Done Turn off MessagingStepPointer.1 and turn on MessagingStepPointer.2 When MessagingStepPointer.2 is true and PLC1-Data_From_PLC2[31]=2 and Turn off MessagingStepPointer.2 and turn on MessagingStepPointer.3 When MessagingStepPointer.3 is true change PLC1-Data_From_PLC2[31]=1 and Turn off MessagingStepPointer.3 and turn on MessagingStepPointer.0 This process should then repeat as fast as comm time will allow. BTW you may want to reset PLC2-Data_From_PLC1[31] to a 2 each time it changes to a 1. This is your indicator in PLC2 you ahve a fresh data set. Please let me know if this works. I've used similiar code between Controlix PLCs before and had success. Please be forewarned that the Cycle Turn Around Time between two COntrolLogix Cpus on ENBT modules could be 5 to 10 seconds in my experience using messages.

[BobLfoot 301]

OK - I AM KNOCKING THE COBWEBS OUT OF MY HEAD - Enough of working Thirds for one millenia. Your best bet between 2 ControlLogix CPUs is the Produced and Consumed tags. Check out the manual found here http://literature.rockwellautomation.com/i...pm011_-en-p.pdf

[lccllc 0]

Thanks bob for the help, I will try this next week when at work, but for now me and my NERD brain are going fishing fo rthe week. Thanks again.

[BobLfoot 301]

No Problem. I can understand the fishin, but my nerd brain has one more 3rd shift to work before the weekend.

[IamJon 0]

^Yes. PC tags will make it easier. Oh, that was a while ago... Have you come back from fishing and gotten back to it yet? Edited 17 Jul 2009 by IamJon

[BobLfoot 301]

Thanks for popping this one Jon - I've gone from 3rds to 1st for a week and back to 2nds for another week since this post staqrted myself. Hope the original poster got his stuff to work. Will be glad to help if you didn't.

[lccllc 0]

Thanks to everyone for the help, and sorry for not posting sooner as you all know when you take time off and get back the work load double's. Bob the produced and consumed tags worked great, problem solved. PC tags make life so much better when trying to share data between to PLC, thanks again guys.

[Peter Nachtwey 15]

I agree that the best way to do this using MSG blocks is to have each PLC read the data it needs. See the first few lines of http://www.deltamotion.com/files/rmcenetclx.zip However, there are problems with this method. The PLC A can be read PLC B's data at any time and the data may not be ready. To ensure the data is ready I recommend that there be a register at the end of PLC B's data that is incremented when PLC B's data is ready. Now PLC A must read the data and check the last registers. If it hasn't changed then PLC A ignores the data. Better yet is to use Ethernet/IP I/O capabilities and map registers in PLC A to PLC B and registers in PLC B to PLC A. Now now message block is required. The that PLC A writes to the 'produced' registers gets 'consumed' by PLC B and show up in PLC B input registers. The hand shaking is very important now because you have know idea of when the data is being transfered back and forth. Again, one must look for a 'sync' register to change before copying data out of the input registers. When writing, one must change all the outgoing data register first and THEN increment the 'sync' register. We use both methods to talk to our controllers. Our controllers look like another PLC. I prefer the Ethernet/IP I/O method and can set that up in about 15 minutes. I do it in training classes. Default update time is 10 ms. I use a 'SyncIn' AND 'SyncOut' register. When I want to send data to the controller I copy the data into the out registers and then increment the 'SyncOut' register. This can happen all on one scan. Then I wait for the 'SyncIn' register to be the same as the 'SyncOut' register. The controller waits for the 'SyncOut' register to change and acknowledges by copying the 'SyncOut' number that it got to the 'SyncIn' register going back to the PLC. Ethernet/IP I/O and Control Logix rock. It is so easy to set up and the speed is so fast. This is INFINITELY better than the Siemens crap I have to deal with now.