D
I am having a communications issue which I am arguing with a vendor in how he programmed it and we have come upon some questions as to how the MSG
instruction works.
We have a dedicated DH+ between to PLC's that runs at 115K. We have a number of events that fire a message instruction to communicate with the other PLC and then close the loop with feedback to the message.
I put diagnostic counters on the events on and off and on the message enable, start, eneable waiting, done and error bits.
The trigger firing the message counter is always higher than the enable,start,eneable waiting, done bits and periodically we freeze up. Also
there are no error counts.
My arguement is that 2 events are coming on at the same time and or are coming on so fast that the message is already busy and misses the "event".
He argues saying that the instruction ques these events.
My understanding of this instruction is this. When a message instruction is triggered the enable bit goes high the data enters a queue so that you capture it at this moment. and then when the processor gets teh token, it pulls the
data out of the queue and sends it and completes the comms. If while enables the rung makes 5 false to true trips, it does not matter as teh instruction is already (asynchromousl) attempting to finish the transfer. It is queued because the processor cannot just push out the message until it gets a token and depending on message size, how long it gets the token.
If you have a busy network full of devices and a lot of data being passed, more time waiting in the queue. I may be wrong but this is a queue not a buffer in the traditional sense of the word.
We have since done a work around to this to my satisfaction by making the message send until a reply is heard which is the way it should have been all along ( in my humble opinion which could be swayed). But I am curious as to why this is....
I still think that is the input condition changes over and over, it is only effective when the message is compete and if it goes on 100 times
(exageration) while the message is active, they will all be ignored IE dropped.
Have never had trouble with this so never have really thought about it this deeply.............
I am in my 15th year od PLC5 education and although I do ok, I admit I am not an expert as there is no such thing even at AB.
Dave Ferguson
UPM-Kymmene
DAVCO Automation
instruction works.
We have a dedicated DH+ between to PLC's that runs at 115K. We have a number of events that fire a message instruction to communicate with the other PLC and then close the loop with feedback to the message.
I put diagnostic counters on the events on and off and on the message enable, start, eneable waiting, done and error bits.
The trigger firing the message counter is always higher than the enable,start,eneable waiting, done bits and periodically we freeze up. Also
there are no error counts.
My arguement is that 2 events are coming on at the same time and or are coming on so fast that the message is already busy and misses the "event".
He argues saying that the instruction ques these events.
My understanding of this instruction is this. When a message instruction is triggered the enable bit goes high the data enters a queue so that you capture it at this moment. and then when the processor gets teh token, it pulls the
data out of the queue and sends it and completes the comms. If while enables the rung makes 5 false to true trips, it does not matter as teh instruction is already (asynchromousl) attempting to finish the transfer. It is queued because the processor cannot just push out the message until it gets a token and depending on message size, how long it gets the token.
If you have a busy network full of devices and a lot of data being passed, more time waiting in the queue. I may be wrong but this is a queue not a buffer in the traditional sense of the word.
We have since done a work around to this to my satisfaction by making the message send until a reply is heard which is the way it should have been all along ( in my humble opinion which could be swayed). But I am curious as to why this is....
I still think that is the input condition changes over and over, it is only effective when the message is compete and if it goes on 100 times
(exageration) while the message is active, they will all be ignored IE dropped.
Have never had trouble with this so never have really thought about it this deeply.............
I am in my 15th year od PLC5 education and although I do ok, I admit I am not an expert as there is no such thing even at AB.
Dave Ferguson
UPM-Kymmene
DAVCO Automation