Creating your own SQLTags driver

For programmers looking to make outside real-time data available to Ignition, SQLTags provide a great extension point. Since the tags are stored in an open format in the database, developers can model their data as SQLTags and then take advantage of everything they offer in Ignition- drag and drop UI config, status overlays, etc.

We’ve created a basic whitepaper that outlines the fundamentals of how to create your own “SQLTags Driver”. The goal of the paper is to get developers up and running, driving simple tags with their own data.

The paper is available here: SQLTags Custom Driver Guide

Attention: This paper is directed towards developers looking to extend Ignition. Normal users, even those utilizing advanced features and scripting, are not the intended audience.

Wow, thanks!

:thumb_right: Great stuff :thumb_left:

Thanks - yet another example of the outstanding service you Guys are providing!


We have already implemented a customer driver along these lines and it works reasonably well for us. We were probably one of the groups you wrote up something like this for before and we thank you for that. The problem I have right now and maybe I’ve overlooked something was in relation to the sqlt_wq table. How does one control now long a write request can be queued in the table and pending before the write is abandoned and error is displayed.

Currently it seems to be set to 10 seconds or so but we have instances where we do not get success code back from the device in time to avoid issues with it believing the transaction abandoned and the hmi displays write timed out. In most cases the time is adequate but we dont necessarily want our operators trying again or getting confused about he error if it eventually does succeed. We do actually ignore subsequent write attempts if one is already active but no good way to provide that feedback after the hmi has aborted the attempt.

Anyway, is this write timeout configurable somewhere? Pretty sure its not the “Fallback Delay” on property bindings.


Yes, I had worked with a member of your company a while ago to get you guys started on that. Glad to hear it’s worked out so far.

That particular timeout is strangely not a settable option. I believe that in FactoryPMI it was set to 15 seconds, but has been increased to 30 seconds in Ignition. If 30 seconds still isn’t enough, I can create a ticket to make it into a settable option.


Gone all week and this is waiting for me when I get back :smiley:

Thank you. Off to create some db tables…

Quick note: The table definition for the sqlt_as table is missing the tagid column

Hi Colby,

What indexes are required on these tables?


Any updated document available with wq table etc. ? or a sample project with db ?

Thank you

The latest version of the Programmer’s Guide in the Module SDK (7.5.2) has a section describing the tables, as well as the historical tables.

I don’t believe it describes the indexes, however. For the write queue, only the t_stamp column needs an index.



I’ve followed the instructions in the ‘SQLTags Custom Driver Guide’ and am updating the value of a tag using the following SQL executing every second:

UPDATE sqlt_core SET floatvalue=second(curtime()),valuechange=now()
WHERE name= ‘MemTag_ND1’;
UPDATE sqlt_sci SET lastexec=now(),lastexecrate=1000,nextexec=ADDTIME(now(),‘0 0:0:1’) WHERE sc_id=2;

The tag’s quality is ‘Good’, but alarms are not being generated when the value exceeds the setpoint
(AlarmActiveAckCount and AlarmActiveUnackCount remain zero).

Is there anything else I need to do?

I am using a MySQL and a non-driving provider.



Unfortunately that’s not quite how it works- if Ignition isn’t driving the tag, it doesn’t “drive” any of it, including the alarms.

If you want to set up an alarm off a tag driven by your value, you probably have two options: 1) Switch to an driving provider or internal provider and switch the tag to an expression tag, with the value generated by the expression or 2) Switch this to a driven provider and update the value by writing to the sqlt_wq table.


Hi Colby,

Thanks a million for the help - alarms are now working.

FYI the SQL I used to test this was:

INSERT INTO sqlt_wq(tagid,floatvalue, typeclass, responsecode, t_stamp) VALUES

Presumably if alarms work then notifications should work too?

And just one more question: Do I need to write something to delete rows in sqlt_wq once they
have been processed? (I’m assuming this is indicated by a responsecode of 1.)

Thanks & Regards,


Yes, notifications should now work. You shouldn’t need to delete the rows, unless you want to- the system should delete them every 10 minutes or so (in reality it might be a little longer, because it checks every 10 minutes, and deletes rows older than 10 minutes).