I am looking to make a connection to a device that is communicating via a custom driver witten in C and running on a Linux PC. We are running the Ignition Gateway and a MySQL datbase on a Window machine. The easiest approach appears to be modifying the C driver to read/write the SQL database in an update mode and then have Ignition do the same for a bi-directional transfer. We have already developed a datbase with a number of points that the C driver is writing to. What is the best way to connect Ignition to this database. Is adding a “Database Driving Provider” in the SQLTags Provider the best approach to create this link? Will this link automatically scan the Datbase and show the tags inside the Designer the same as connecting to an OPC server does?
Thanks,
Kurt
OK, I am reading the guide. We’ll give it a shot and see where we run into problems. We have the appropriate tables in a MySQL database. In sql_core, what does path refer to? Path to what? Assume this works then we should see the Driver and the tags in the SQL Tags browser, correct?
The path is the path to the tag. It might be easiest if you create an external sqltags driving provider, and then create some OPC or DB tags through the Desginer. This will help to give you examples of what configured tags look like.
Ok, sort of there.
Step 1.
I went to SQL Tags -> Realtime and added a new Database Driving Provider, which I call “camac”. I hook it to my already existing Datbase connection. I am a little fuzzy about what should be in for the Driver Name. For now I leave it defaulted to “ignition”.
All the appropriate SQL tables are in my database.
Step 2.
OK seems straightforward. I add a new scan class entry to the sqlt_table.
Step 3.
Ok in the Designer CAMAC shows up under the SQL Tag Broswer (All Providers). I add a tag it shows up in the sql_core database. I add a tag in the sql_core database, and it shows up in the Designer. I add another tag with a number not equal to 0 and it shows up with the right value in the Designer. I am using the new scan class.
Step 4.
I pick a tag and change the value of the tag in the designer and it changes in the sql_core database. I change the tag value in the sql_core database and update the valuechange time in sql_core. No change to the tag value in the Designer. I update sql_core and update sqlt_sci. No change in the designer.
Step 5.
I change the Driver in step 1 to “camacdriver” which is a name I just make up. I go to the designer and go to the tag and change the driver to “camacdriver.” The value in the tag blinks between 0 and the new database value a couple of times and then stays with the new database value. I update sql_core and sqlrt_sci a couple of times and no change in the designer.
What am I missing?
Thanks,
Kurt
Well in case anyone is reading this thread I got it working (after calling technical support). You have to use a Database Provider and not a Database Driving Provider. The whitepaper states in Step 1 that you can use either one but this does not appear correct.
I looked into this after our call Kurt. The whitepaper currently says that creating a Database Driving Provider is an easy way to create the tables you need to interact with SQLTags. It does not say that the Database Driving Provider should then be deleted and and a Database Provider should be created for using your custom driver. Sorry for the confusion, the whitepaper will be updated as soon as possible.
Just to be ornery it actually says “Since the Driving Provider also acts as a standard provider, you can use just that.” Acutally you can’t use it at all except for creating the tables.
Do you have any further white papers or extensions regarding this topic, specifically regarding write requests?
Thanks,
Kurt
Sorry for the confusion here, but that sentence is perfectly correct.
It should be absolutely possible to use the driving provider. There could be something wrong, but I doubt it, since I currently have a FactorySQL set up driving SQLTags, and an Ignition with a driving provider set up sharing those tags and driving its own.
From a code point of view those two provider types start from the same point. The Driving provider simply goes further and will execute any tags whose “driver name” matches the setting on the provider.
There must have been something else going on when you tried to use the driving provider.
If the Database Provider is working for you, I’d recommend sticking with that. I just wanted to clear up the confusion that it is, indeed, possible to use the driving provider.
We’ll update the paper soon to talk about write requests. It’s really pretty simple though: an entry is placed in the sqlt_wq table with a responsecode of 2. Your app would poll the table for new entries (something like, “where responsecode=2 and id>Last_Known_Id”) . When the write is complete, you write the result (0- Failure, 1- Success) and an optional message. The provider watches for entries whose response code != 2, so there’s no need to update the timestamp.
Regards,
Re-reading this thread, it appears that there might be one point of confusion that I can clear up: the driver name.
Each SQLTags driver should have it’s own name. It will execute (that is, generate values for) any tags who have that name as their “drivername”. For any tags that don’t have that name, it will simply monitor their values.
If you were to create a driving provider in Ignition, it would have a name (by default, “ignition”). If you’re writing your own driver, you would want to use a driver name for your tags that is different. That way, Ignition will only monitor those tags, and not try to execute them.
Don’t know if it helps (sounds like you’re up and running now anyhow), but at least it addresses a question you posed in an earlier post.
Regards,
Robert and I couldn’t find anything obviously wrong so it must have been a more subtle problem. What was interesting about the driver name was that in the Designer when using the Database Driving Provider the value would show up properly for the Tag if you configured the Tag to use any driver name except for the name that was entered in the Configuration for the Database Driving Provider.
As far as write requests. How does the entry get placed into Sql_wq. I get an error if I simply use the “Set Tag Value” and try to write a value directly to the tag. If I need to write an entry into the Sql_wq table using the “SQL Update” option I can only write one value per mouse click. Would I need to use the “Script Editor.” Is TagID the integer in the id column sqlt_core or the string in the name column? The later two approaches seem a little inelegant.
Thanks,
Kurt