Yes I have watched the video which is where I came up with the idea. However a small minor glitch occurs if a machine is taken offline. It reports back all NULL information and starts adding to the database instead of updating the database. What I am trying to accomplish is finding something that does not change if communications are lost and using this as my key index field.
The idea that I had come up with was to use the _DeviceID, this is a value that is set in KepServer and even when communications with the PLC is lost it still maintains its information. The problem with this tag is the fact that it comes across as an ASCII not as an integer.
If I use the machine_num field it works quite well, that is because this number come across as an integer. But like I said if communications is lost then this integer reports back as a NULL and it adds another row of information in the database. This is why I want to use something that does not change, a fixed value sort to say.
For some reason though when I used the _DeviceID tag it did not record the data in the database. Was it because it was ASCII? Dont know. All I do know is when I used it it always left that field blank. SO I had nothing to compare things with.
I hope this makes sense. You see sometime a machine is removed from the production floor to either go out and be retrofitted or rewired. So if that machine is gone I dont want it adding anything to the database.
[quote=“nathan”]The index that we’re referring to (tablename_ndx) is an autoincrementing primary key that uses the database to keep track of the numbers. In the case of keeping your own machine numbers you would want to add your own column to the table that FSQL creates. It will create the row for you if you specify “WHERE {your_row}={your_value}” in the groups custom WHERE clause. I’ll give you an example.
A common application with multiple templated machines is to have an FSQL group for each machine. Add a “machine_number” column to the table. Each FactorySQL group would have a custom “WHERE clause”, for example “WHERE machine_number = 26” for machine/group 26. The catch is that the item names (columns in the table) should match up. It’s OK if certain machines have extra values - just make sure to show it properly on the HMI side. The really nice benefit of this approach is that a machine is represented by a row. You can easily set up a FactoryPMI screen that is one window that could be used for all 26 machines. The entire screen’s data is based on a query that reads all the selected machines info with a “WHERE machine_number = {my_selected_machine}”, where {my_selected_machine} is a FactoryPMI dynamic property that the user sets via: buttons, a drop down list, etc.
This approach allows you to only create one screen for all similar machines. Adding a machine is simply a matter of adding a new FactorySQL group. You can even populate the users list of choices in a dropdown based on the rows that are in that table. You can see a similar example in this FactoryPMI quick start video.[/quote]