Which approach to follow - Tag Historian /Transaction Groups/Tag Event Script and Query Tag/Named Query

[sharmila.belvalkar]

Can someone provide guidelines to decide which approach to follow in which case?

[PRAMANJ]

Each one is for different purpose, depends on what you want to do!

[pturmel]

There's no general rule. Tell us what you are trying to do. But these links might help:

SQL Tall/Long vs Wide Table Structure

I am in the process of trying to collect high speed historical data to an MSSQL database. We would like to collect data to set up a predictive maintenance system. We would like to collect information like temperature, vibration, voltage, current, etc. on CNC machines on a per machine cycle/part cycle basis at a 100mS sample rate. We would then like to compare the charts based on machine/part cycle to set thresholds and detect abnormalities before they become breakdowns. We are collecting all…

Organizing SQL tables and named queries efficiently

If you have a bunch of machines, and multiple events to track, is it best to have a transaction group for each event type, and for each machine? I read one guy say if you had a bunch of machines, you wanted to organize all of them into one table. I thought the limitations on SQL were that as a table gets bigger, the queries slow down. So I thought that if my tables are split up, then my tables will be smaller with the same total growth.

Second guessing architecture

I’m currently writing maintenance documentation for what is officially my first Ignition deployment in the wild. The system is a data concentrator that monitors multiple identical machines and writes a consistent set of data to two different DB tables - one table has one row per machine and is updated in real time with various state values. The second table archives other data on the completion of that machines current instruction, and has one row per instruction. There is no UI on this proj…

[zacharyw.larson]

I am new, but as a general rule for myself:

Data Collection from Machines
I find that the work to create the transaction groups creates a very uniform and standard approach that results in clean and organized data. It has been great for data that is automated from machines.

I saw a person using the python updating for this, and it seemed like they were extremely picky which tags on which machines, and it got rather complex quickly I thought. Their data is very accurate, but in doing so I thought that they avoided using a standard method that would then force/encourage standards on the plc programs in the machines.

Any manual entry data, interface buttons, tricky customization
When I have people doing some manual entry, I like the runprepupdate system function in python scripting. This is the case even if most the data is automated.

This has been useful in cases where I wanted to use subsets of table to delete rows as well, like if a user clicks on a row and then presses delete, the query is easy to run as a script.

In some cases I think that there are more complex things that you can do easier with the scripting. I think it is a tradeoff though between standardizing the plcs or doing this custom scripting for me. Some customization of the tables, like coloring cells, I think is done in the scripting.

Ad Hoc Trends, Power Chart, exchange visualization
I have many historized tags specifically for use with the data visualization resources on the exchange.
The historizing creates for me a uniform tabulation of the data that then works great with these premade resources.