Plc5 - Msg Instruction

Join Date
May 2002
Posts
4
PLC5 - HELP - MSG (INSTRUCTION).

When PLC5 is receiving a block Message whith 32 words from another Station thrue DH+ network, how he spread the data in to the data tables and when is the data available in the scan??

- He wait's for all the packets and then he dump's all the data in just one time or he dump's the data each time he receive a packet.


Thank's for your help.
 
I think I understand what you're asking, Walter; when a large message is sent across DH+, is it fragmented or does the whole message arrive at once ?

The answer is that it arrives all at once. DH+ messages can be up to 122 words long, and they are all collected from the source PLC and delivered into the target PLC data table in a block.

However, if you're the target PLC of a DH+ message, there's no way to tell when the data has been updated, other than clearing out the incoming data table and waiting for it to change.

If your PLC is the initiator of a MSG Read instruction, then you can rely on the Done (.DN) bit to tell you when the data has arrived.
 
Thank's for you help Eddie, but i will be more specific:

I'm sending 32 words of data from plc "A" to plc "B", my first word (N10:0) always have the bit 0 and the bit 1 true, also my last word (N10:31) always have the bit 15 true.
On the Plc "B" each time i receive the block i copy him and i clear all the 32 Words,
Sometimes i receive the bits from Word 0 but i not receive from Word 31, and how i now that because i maked a simple code to catch the event.

N10:0.0 N10:0.1 N10:31.15
|---| |-------| |-------|/|---------------(L)---|




Bye.
 
You said you're sending from a to b. So I assume there is a msg write in processor a. In that case, b might not get the data synchronous to it's program scan. If you instead do a msg read, initiated by processor b, to "go get" the data from processor a, then use the .dn bit from the msg read control file, you'll have better luck.
 
I have run across this kind of thing in the ControlLogix, in which a message across ControlNet lacked data block integrity because it was bigger than 128 words (the max size for PCCC messages) and thus was transmitted in different network updates.

This is not, to the best of my knowledge, the case in the PLC-5 with DH+. The whole block of data should arrive all at once and be put into memory all at once.

Try that trap logic rung in the *sending* processor. Maybe the data is changing before the MSG instruction has a chance to grab it from the data table. This might especially be true if you're sending a lot of messages from that PLC and the MSG instructions spend some time waiting in a queue.
 
I won't claim absolute certainty on this, but I think you'll find that the data table is updated asynchronously to the program scan as the data arrives - in bytes.

You will need to implement a 'hand shake' protocol to ensure that all data has been received before using any portion of it. This might be as simple as adding a flag to the end of the data block which you can test in the receiver to indicate that the whole block has been received - then accept the data, reset the flag, and wait for the flag to be set again.
 
While probably on a low level the message data is put into the data table bytewise, from an application perspective it's definitely either as a block or per data element. Otherwise you could never trust an incoming data element of more than one byte (and that's all of them, integer and floating-point) to be the correct value.

I happen to be visiting A-B headquarters tomorrow morning and meeting one of their DH+ experts... I'll ask her about this !
 
Eddie

I'm basing my statement on some 'ancient' experience with PLC2's and DH where the changes definitely occurred byte-wise and asynchronously.

Definitely a trap for the unsuspecting!

Please pass on the words of the expert.
 
I was referred to one of the PLC-5 firmware guys at Landerhaven and he said that while data is moved from received messages into the data table asynchronously to the program scan (it actually transfers between two microprocessor subsystems), it happens so fast that you shouldn't be able to detect it with a ladder logic application.

The data is definitely moved element-by-element, not byte-by-byte in the PLC-5.

As has been recommended earlier in this thread, if you're concerned about the occurence of data update you need to run a MSG Read and you can trust that all the data has arrived in your data table when the DN bit comes on.
 
it happens so fast that you shouldn't be able to detect it with a ladder logic application.

That sounds like wishful thinking! The elapsed time from one rung to the next is "really fast" too.
 
It's not impossible for a received data block over DH+ to be viewed by ladder logic as incomplete segments, but it's very unlikely. The whole data block will arrive eventually, so the simple thing to do would be to wait for the last data element to change before acting on the data in the block.

But if some of the block data doesn't appear at all, I'd start monitoring the sending MSG instruction. If it errors, check the error. If it doesn't, check the .EW bit and find out if the MSG instruction is sitting in the message queue for a while. Maybe the source data is changing.
 

Similar Topics

I programmed a couple of MSG instruction for a PLC5/80E to write and read data to a SLC 5/05 thru an Ethernet network on non-continuous mode. It...
Replies
1
Views
2,492
I digged through different documentation, spent hours trying to accomplish it and still didn't get results :( Please help!! I have...
Replies
16
Views
13,071
Hi, I'm trying to use only one Msg Instruction where the Source and the Target addresses are Indexed (Dynamic), i made that using an Integer (N)...
Replies
1
Views
6,511
Hi, I'm trying to use only one Msg Instruction where the Source and the Target addresses are Indexed (Dynamic), i made that using an Integer (N)...
Replies
0
Views
5,859
Hello, I have a question regarding the possibility of using messages instructions to communicate between: PLC5/80E Series D - CE Water Mark...
Replies
12
Views
3,048
Back
Top Bottom