FactoryPMI/SQL Realtime Engine

[12brich]

You are right about all the sophistication hooks built into FSQL. It seems to be very clean overall. It probably has many levels of exception handling that quick code cannot achieve.

Right now, I am using an OPC Server toolkit and it does reduce development time tremendously. It would probably take many more hours to get it down right and clean. As far as SQL code, we do have some existing applications that we can reuse. We did all this because we have to. If you have an engine, we'd love to buy.

I totally forgot about the SQLTags on the FSQL side, thanks for letting know. I will look into it more. We may have to get both packages.

 

[surferb]

That's good - leverage existing code/packages to the extent that you can before reinventing the wheel. Evaluate FSQL/FPMI fully before making any purchasing decisions - the demo just must be manually reset after running for 2 hours.

I seriously doubt that any existing OPC engine/SQL dataloggers on the market will directly meet the needs that you described. For your due dilligence, other options to consider would be Rockwell's RSSQL and Software Toolbox's OPC Datalogger.

I've never used .NET "datalogging engine". A quick Google search yielded this. I think logging (INSERTING records repidly to an SQL database) should be straightforward to program. I would recommend comparing performance of sending relatively large sets of INSERT queries at a time versus using stored procedures. I can't think of a good reason to use stored procedures for a data logging application. Also, be sure to use a table type/engine that's ideal for that sort of data and index the table by whichever column you'll be sorting/searching against (timestamp, most likely). I've also found that, with the engines that I've tested, "wide" tables seem to perform notably better for historical data than "tall" tables. This goes against basic database 101 static schema design. The key factor depends on how frequently you change the tags that you wish to log. Change a lot - go with a static schema.

Hope this helps - I'd be happy to provide whatever insight I can if you have specific questions.

You are right about all the sophistication hooks built into FSQL. It seems to be very clean overall. It probably has many levels of exception handling that quick code cannot achieve.

Right now, I am using an OPC Server toolkit and it does reduce development time tremendously. It would probably take many more hours to get it down right and clean. As far as SQL code, we do have some existing applications that we can reuse. We did all this because we have to. If you have an engine, we'd love to buy.

I totally forgot about the SQLTags on the FSQL side, thanks for letting know. I will look into it more. We may have to get both packages.