Polling Sequence with RSLogix5000 and AB PLC's

Tpetie3509

Member
Join Date
Apr 2017
Location
Washington
Posts
23
Hi all,

I am setting up a PLC for data aggregation from multiple remote sites (35-50). Before I get too far into this here is the equipment and software involved.

CompactLogix L30ER 1MB Controller (Master PLC) - RsLogix5000
ML1100 Controllers (Remote Site PLC's) - RsLogix500
Wonderware as SCADA host

I have a bench station set up and have gotten to the point where I can read/write data to and from the Master to the 'slaves' on a network. Currently Wonderware is polling these sites directly and creating what I think to be a bottle neck in the network traffic since there is no way (that I have found) to sequence the polling of each site, hence why I am adding this master controller to handle messaging in a sequential pattern.

Here is my question: Is there a standard for sequencing polling from several remotes? My thought is to just use a 'master timer' that will run for a set amount of time and using EQU functions to fire each rung for each remote and then restarting the timer and so on and so forth. I can't help but to think someone, if not many of you have put something like this in place before and may have some ideas.

**I have used the 'Messaging with RsLogix5000' documentation and gotten myself up to speed on basic messaging practices.

Any input is appreciated.

Regards,

Todd
 
What I have done is a master time that just keeps polling each of the PLC's on the network.
The program in each of the PLC's will store the data until the polling station gets the data. The information is not lost when polling does not happen.

Regards,
 
That is something I would like to have also, currently all of the remote PLC's don't store any data and if polling fails, the values will only populate to current when the polling is healthy again. Do you know if it's possible with ML1100 controllers to store this data?

Thanks,

Todd
 
I use a state engine to drive the polling. I use a timer to insert a minimum delay between each message. I use the DN and ER bits from each message to advance to the next state.

I use "config bits" to enable/disable stations. I work mostly with ML1400 and Click as the master PLC. The ML1400 will not allow online editing of rungs containing MSG instructions. By using a state engine (a series of mutually exclusive bits), My message logic is just examining a state bit and a MSG instruction. I completely control the sequence in separate logic without touching the MSG rungs so it can be done on the fly.

I will also have a timer that measures the complete poll time and I will store the fastest and slowest poll times. I like to show on the HMI the status of the polling so that you can visually tell where the hangups are happening (and they will happen!).

attachment.php


attachment.php


Radio MSG States 000.jpg Radio MSG States 001.png
 
That is something I would like to have also, currently all of the remote PLC's don't store any data and if polling fails, the values will only populate to current when the polling is healthy again. Do you know if it's possible with ML1100 controllers to store this data?

Thanks,

Todd

All the data in all Allen Bradley PLCs is retentive. Nothing will be lost.

For comms checking...normally, the first element of my MSG is a "Heartbeat". It is just a number that increments or a copy of the free running clock...think of it as a random number. In each slave, I will watch for this value to change.

If it doesn't change for 1 to 10 minutes (depends on situation) I will set an alarm and take appropriate action. In the master PLC I will receive a heartbeat for each slave, so that if it doesn't change, I know that PLC is not running or not communicating. So in the main PLC I will have a comms timeout alarm rung for each slave RTU. I will map those timer accumulators to tags for each slave called "data age" or something to that effect. In the HMI tooltip, where available, I will explain it as the number of seconds since the last successful read took place.

Note that a PLC can communicate just fine when it is simply faulted, so using a heartbeat rather than just relying on MSG error bits proves that not only is the RTU communicating, but it is in RUN mode.
 
Last edited:
All the data in all Allen Bradley PLCs is retentive. Nothing will be lost.

For comms checking...normally, the first element of my MSG is a "Heartbeat". It is just a number that increments or a copy of the free running clock...think of it as a random number. In each slave, I will watch for this value to change.

If it doesn't change for 1 to 10 minutes (depends on situation) I will set an alarm and take appropriate action. In the master PLC I will receive a heartbeat for each slave, so that if it doesn't change, I know that PLC is not running or not communicating. So in the main PLC I will have a comms timeout alarm rung for each slave RTU. I will map those timer accumulators to tags for each slave called "data age" or something to that effect. In the HMI tooltip, where available, I will explain it as the number of seconds since the last successful read took place.

Note that a PLC can communicate just fine when it is simply faulted, so using a heartbeat rather than just relying on MSG error bits proves that not only is the RTU communicating, but it is in RUN mode.

I fully understand this portion and thank you for that. I'm not sure I understand some of the control you have set up for your messaging.

I have mine set up so that it increments to the next message with the previous done or error bit. I can also see how adding an "enable/disable bit to each station would be beneficial.

What is the purpose of the FLL instruction if you are using a message instruction anyways?

Also, is the poll time timer just a timer that starts with the message.en bit and stops with the message.dn bit, then reporting that time back before resetting during the next poll?

Thanks,

Todd
 
That is something I would like to have also, currently all of the remote PLC's don't store any data and if polling fails, the values will only populate to current when the polling is healthy again. Do you know if it's possible with ML1100 controllers to store this data?

Thanks,

Todd

In my case, I log the time and date with the values that need to be logged. This is done through indirect addressing. When polling the PLC, I read the indirect address pointer. This is the ending location. I know the starting location in memory, so I can read all of the information. I then read the indirect address pointer again. If it has not changed, I write the beginning address of the log back into it.

Regards,
 
In my case, I log the time and date with the values that need to be logged. This is done through indirect addressing. When polling the PLC, I read the indirect address pointer. This is the ending location. I know the starting location in memory, so I can read all of the information. I then read the indirect address pointer again. If it has not changed, I write the beginning address of the log back into it.

Regards,

So you are logging in the remote PLC at a date and time interval? I'm a bit confused on how you get the in-between values. If I poll and don't receive anything new for a few scans, then communication returns and I get a new value, the data will fill in the blanks but it will show the last known value up until communication is reestablished. Hopefully I'm not confusing this, just trying to understand your method.

Thanks,

Todd
 
What is the purpose of the FLL instruction if you are using a message instruction anyways?

It just clears all the state bits before setting the next one.

Also, is the poll time timer just a timer that starts with the message.en bit and stops with the message.dn bit, then reporting that time back before resetting during the next poll?

My poll timer gets reset on the rising edge of the last state, but first I capture the accumulator by moving it to an HMI tag and do the "high score/low score" logic to update the peak values (fastest and slowest poll times).
 
It just clears all the state bits before setting the next one.



My poll timer gets reset on the rising edge of the last state, but first I capture the accumulator by moving it to an HMI tag and do the "high score/low score" logic to update the peak values (fastest and slowest poll times).


That makes sense, thanks for the explanation. I am going to try some of this and see if I can't come up with my own version that will function well with my application.

Thanks again,

Todd
 
I have set the logging up to show minute by minute of what is happening with the line. If there is nothing to bring in with the log then I read the actual current value to display.
The minute by minute log is then being stored in a database.

Hope this explains it.
 
gclshortt and Okie, just wanted to thank you guys for the support. I am moving forward with the logic on this controller and making progress quicker thanks to you guys! (y)
 
I maybe going off on a tangent there, if this is for civil site monitoring application then a better system maybe "data-logger" from Campbell Scientific which is designed for radio polling data from field stations.
 

Similar Topics

Dear Experts, Thanks in advance for your kind help. I have a GEO SCADA expert 2022 and configure it as a DNP3 master, also I have multiple DNP3...
Replies
0
Views
585
I am trying to figure out some communication specifics for a Modbus RTU network that I will be integrating with and could use some help to make...
Replies
9
Views
1,925
How many tags can be polled per second or per minute without throwing plc in error or running into problem. Thanks.
Replies
5
Views
1,966
Trying to recover an old well controller ML1000 using DF1 Half Duplex and my RSLinx won't allow me to create a DF1 Polling Master Driver. I am...
Replies
2
Views
1,462
I am setting up a system where M580 is Modbus Master data concentrator. I have the Read_Var polling setup, my question is how do you guys handle...
Replies
2
Views
1,632
Back
Top Bottom