Folder based scan classes, and other polling related feature

I have a number of features that I’d be interested in with Ignition as it pertains to Scan Classes.

First would be to make it so Scan classes could be associated with a folder and its subfolders, rather than having to tie it to each tag inside the folder. Would work best if there was an override where you picked “Inherit” or you could pick a different class on each tag. This is more of a convenience thing though.

The way we’re using the scan classes now is that we create a separate scan class for every folder in the system, and we tag each of those to a _Demand_Scan database tag in that folder. We then use momentary buttons to turn on the demand scan and poll the items. You can imagine that with 300 folders, this is a big maintenance overhead. It would be helpful if we could make one scan class that would use a relatively specified trigger for the tags, so that the tags in folder 50 would poll when 50/_Demand_Scan was triggered, and the tags in folder 100 would poll when 100/_Demand_Scan was triggered. Alternately, the scan class could be just another element in the folder instead.

Another issue is that there’s no good way to tell the user when their tags were last polled. We were lucky on the last project we did and had a float variable that is continuously increasing, so we could look at that variable’s last update value. The devices I’m working with now don’t really have any values guaranteed to be changing. Some scan class tag that said the last time a poll was completed would be helpful.

Lastly, right now the Driven mode just tells it to continuously poll while the condition is true. I’ve encountered problems with this model where sometimes it wouldn’t complete a full poll before the driving value went away, or it would do a whole bunch of polls in that time. A better way of doing this would be either to have another “Triggered” mode where the value going low to high would make it complete a single poll, or something similar where it would complete a single poll, then set a tag to a user defined value.

I’m having a hard time wrapping my mind around your setup. Would you mind providing a business (non-technical) kind of description of what you’re doing? What determines when you need to poll quickly or not at all for groups? Should the “off” groups be updated slowly or not at all? About how many tags are you communicating with in each group and what kind of update rates do you require? Have you experienced too much traffic with driven tags on a false condition?

Your “triggered” comment leads me to believe that you may be working on an application better suited for “SQL Bridge” groups or transaction groups, rather than (realtime) SQLTags. Let’s consider the problem from a “higher level” first before getting too far into the weeds with Scan Classes.

The polls are triggered by a user hitting the poll button. They need realtime data, but only when they decide that they need realtime data. Many of our wells are on serial radios and on cellular modems. The serial radios we only want to poll when the user needs the data because otherwise their polls would get in the way of other automatic polls we do. On the cellular modems, every poll runs up more bytes on the line, and if we were to poll continuously it would cost too much. But, we want the user to be able to poll every 3-4 seconds if they really need to see what’s going on at the site. We also have dozens of cell modems and hundreds of separate sites that need to be polled, but we only want to poll one site at a time.

That makes sense - after posting I thought about really low bandwidth or expensive connections - cell modems certainly qualify.

You can achieve some of the same effect without SQLTags with “triggered” groups. This approach, that we used heavily in (pre-Ignition) FactorySQL and FactoryPMI, would update the SQL database when users want to poll, then use Vision to graphically represent the database values. It gives you better polling control, but even less tag status especially with respect to error codes. You do get the t_stamp field that provides the datetime of the last update. With clever screen design, you can make the status obvious to the user and give them the ability to force updates.

Transaction groups may gain you efficiency benefits - @Colby or Travis, what do you think?

A lot depends on what your doing, how cheap you want to be with bandwidth, and how users expect the program to run.

Whatever the solution is, we need to be able to configure it through scripting, internal or external. We’re using sqltags right now because we’ve figured out how to create the tag list once for each variation of a device out in the field, then replicate it across all of the devices that are identical to that using external python scripts.

We’re currently using an OPC COM DA2 server that has all of these features built in, but using sqltags with OPC COM DA2 and a pair of database driving/database sqltags ignition instances is glitch prone and problematic, so now I’m trying to figure out a way to use the built in modbus server in a way that matches the current opc server.

(The solution would also need to handle having 100k tags.)

have you looked at using a different polling server? with that many tags/devices I would look to use something robust and easy to configure, and easy to troubleshoot.

I use universal server and so far have around 28k tags/750 devices and it is solid. a polling server like USS is made to handle large amounts of devices and provides lots of tools for troubleshooting devices and circuits. It also has demand scan option like you are looking for along with a last poll time tag available for each device. you also have the capability to schedule the devices to poll at specific times and on what interval you want them to poll.

Also, It was recommended to me to use a opc-ua wrapper, since universal server is DA only.

Universal server is the one I’m using.

The DA wrapper worked, but couldn’t be used for browsing, it kept timing out. I went another direction.


First off, I should mention that for 7.3, we have implemented a few new options on scan classes that will help you:

  1. Driven scan classes now execute as soon as the tag value changes to meet the condition
  2. There’s an “any-change” comparison mode, so you can trigger just once on the rising and falling conditions
  3. There’s a “one-shot” mode, so you can set it up to execute one just on the rising or falling edge of the condition.
  4. Scan classes can now be set to “read” mode instead of “subscription” (like the “opc mode” on groups). That way, nothing is subscribed - when the scan class executes, it manually reads the tags from the opc server.

So, that will help a lot with the actual execution. In regards to the configuration, I’m afraid not much will change right now, but I can take your suggestions into account for the future. It’s fairly easy to use the tag search feature to change the scan class for many tags at once, though I know you’d like a more automatic (and less error prone) system.

In regards to the “last execution”, for 7.3 we’ve also added new Gateway Status tags. We can add status tags for each scan class, including the “last exec” time. You could then fairly easily read this value with an indirect binding or a script on a status window.

Let me know what you think about all this, and if I’ve missed anything.


And since I have ESP, I should anticipate your next question: 7.3 has been pegged for release on Oct. 3rd.

[quote=“ekthomson”]Universal server is the one I’m using.

The DA wrapper worked, but couldn’t be used for browsing, it kept timing out. I went another direction.[/quote]

just wondering what wrapper you were using? I am using kepware version 5.5

Its been very reliable for me, but I never use opc browsing from ignition anyway. I just use csv files to make my devices. If I do need to browse I just use matrikon explorer.

Thanks for making those updates. I’ll try those out in October and see if they improve the handling of the various tasks.

I believe I can do the scan class settings with my existing python script.

As far as OPCUA wrappers go, we were using the Matrikon OPCUA wrapper and couldn’t get the browsing to work reliably. If we end up revisiting OPCUA wrappers to universal, we’ll try the Kepware one next time. It would be better if Universal supported UA directly. Maybe I’ll send them a query on that.

good luck with that!

On a side note, our company has a modbus polling driver that runs inside of Ignition, and has the ability to change polling priorities on the fly, and gives more detail than the standard modbus driver. For more information, give me a call or send me a pm.

And on the other side (note) my company has a data collection front end that handles DNP (and soon 61850 ) and various others. (not OPC though) We turn them all into SQLTags for your data manipulation pleasure.

[size=50]not to compete with Kyle but we also do modbus[/size]