slick_william
Member
I know this thread has been stagnant for a while but wanted to share my thoughts on sequential MSG instruction polling/writing from your CompactLogix (and general sequential polling logic):
Tips:
1) It's a good idea to do what you said and use a master polling counter (index) which keeps track of which site you are polling. I like to number each site by using the tens and ones digits...
for example 110 might be site 11, message 0, and then it completes 111 (site 11, message 1), and 112 (site 11, message 2) then jumps to 120 (site 12, message 0) and so on.
We can call your index counter "CTR" for now and make it a DINT.
2) It's a good idea to include a monitoring timer to make sure your polling doesn't hang on any step. If the CTR value doesn't change in a SP amount of time (.pre = 3000 etc) then you handle the timeout somehow. You can skip that message, or that site, or generate an alarm, but the idea here is to have an EQU or NEQ function to make sure the CTR index doesn't hang for more than a set amount of time.
If your CTR monitoring is set up correctly then your polling should never hang for more than a few seconds. It'll go from Step 1 to Step 2, ... , and all the way back to Step 1 every time, in permanent looping fashion. You can even display the comms step on SCADA or the HMI touchscreen.
3) Make sure you consider what will happen on PLC power up / first scan. Some comms routines use only .DN and .ERR contacts in parallel to fire MSG instructions, but this alone will not start the sequential polling without a FS bit or something like that.
If you have some kind of error-checking logic you can account for all potential site hangups as described in (2) above. You also want to account for comm fails to individual sites and other cases like power outages, etc.
4) You can set the timeout parameters of the MSG instruction by setting the timeoutmultiplier and a couple other parameters of the MSG tag. This ensures that the MSG instruction will not try to poll for 30 seconds if it doesn't need to, as can happen if you have a site that is down and 4 messages going to it (introducing a 2 minute lag if you only use the DN and ER contacts in parallel)
5) I like to include a minimum time SP (as another user described) to limit how fast the messages will fire, to limit the traffic on the ethernet or other network.
Just wanted to get those thoughts down since I was looking at this very fine thread and thought I could add some tips. Thanks all, happy PLCing!
Tips:
1) It's a good idea to do what you said and use a master polling counter (index) which keeps track of which site you are polling. I like to number each site by using the tens and ones digits...
for example 110 might be site 11, message 0, and then it completes 111 (site 11, message 1), and 112 (site 11, message 2) then jumps to 120 (site 12, message 0) and so on.
We can call your index counter "CTR" for now and make it a DINT.
2) It's a good idea to include a monitoring timer to make sure your polling doesn't hang on any step. If the CTR value doesn't change in a SP amount of time (.pre = 3000 etc) then you handle the timeout somehow. You can skip that message, or that site, or generate an alarm, but the idea here is to have an EQU or NEQ function to make sure the CTR index doesn't hang for more than a set amount of time.
If your CTR monitoring is set up correctly then your polling should never hang for more than a few seconds. It'll go from Step 1 to Step 2, ... , and all the way back to Step 1 every time, in permanent looping fashion. You can even display the comms step on SCADA or the HMI touchscreen.
3) Make sure you consider what will happen on PLC power up / first scan. Some comms routines use only .DN and .ERR contacts in parallel to fire MSG instructions, but this alone will not start the sequential polling without a FS bit or something like that.
If you have some kind of error-checking logic you can account for all potential site hangups as described in (2) above. You also want to account for comm fails to individual sites and other cases like power outages, etc.
4) You can set the timeout parameters of the MSG instruction by setting the timeoutmultiplier and a couple other parameters of the MSG tag. This ensures that the MSG instruction will not try to poll for 30 seconds if it doesn't need to, as can happen if you have a site that is down and 4 messages going to it (introducing a 2 minute lag if you only use the DN and ER contacts in parallel)
5) I like to include a minimum time SP (as another user described) to limit how fast the messages will fire, to limit the traffic on the ethernet or other network.
Just wanted to get those thoughts down since I was looking at this very fine thread and thought I could add some tips. Thanks all, happy PLCing!
