Hi All,
Just hoping to find out if someone has tested Ignition V7.9 or V8 on the above hardware?
The client wants to consider using the existing hardware.
Application is a simple vision, reporting and historian module for a process plant. And print/e-mail historian data at specific time during the day.
Any help or advice appreciated.
Cheers
Ignition runs on Java, so pretty much on any OS.
And the 24 GB of RAM you list is certainly plenty to run Ignition if not too much, I would limit the RAM Ignition gets to 2 or 4 GB. If you give it more RAM, Java can become greedy, and eventually choke in the excess of memory.
The ram usage does depend a bit on the size of the reports though. As those are generated on the server. If you want to generate big reports, you may need to assign it more RAM.
Hi @Sanderd17
Thanks for your response.
The plant has a few Siemens S7-1200s on Profinet and a few AB PLCs on Ethernet/IP.
And the reporting only takes temperature reads for a process and size of the file might be < 5MB per report.
So having had the Ignition 7/8 Installed on the above server module, will the below proposition work?
->All the PLC devices connected to the server through a managed switch.
->Have Ignition clients running on factory PCs to review the process or extract report data from the Server (Unlimited Clients??)
->E-mail reports by setting up a dedicated E-Mail using clients factory SMTP/Mail server.
Ignition Modules for the application:
OPC UA Server Module
Alarm Notification Module
Tag Historian Module
Vision Module Unlimited
Allen-Bradley Driver Suite
Reporting Module
Siemens Driver
DNP3 Driver
The purpose of the SCADA is to view process data on Iginition client PCs in the factory and have E-Mail/Alarms for reports and required process data and have a history of tag values in a database to go back in time if required to analyse data.
Any suggestions if this is suitable or will this require additional licensing or modules ?
Any thoughts appreciated.
Cheers
I would suggest the SQL Bridge Module, the transaction groups are very powerful and I favor them over tag history.
Hi @dkhayes117
So you would suggest replacing the Tag Historian Module with the SQL Bridge Module?
Cheers
The working is just different. The Tag Historian is very automated and is meant to store the history of single measurements, including easy ways to query that history, display it in a graph, ...
The SQL Bridge is more meant to log situations (a group of tags) when a state changes. But the way you store the data isn't fixed, so you have more configuration to do to write and read the data.
We always use the tag historian and configure it on our custom types (UDTs). That way, every instance of a measurement, motor, valve, ... gets a standard history we may need to investigate a problem.
You've got me curious, and since I won't have time to play for a bit, I'll ask the expert. 
does historizing a UDT capture all the elements at once, or do you need to historize each element separately?
Hmm, perhaps a wrong choice of words. We don't historize an UDT (I don't know if it's possible). But per UDT, we select what to historize (motor frequency, motor amperage, valve state, measured value, ...). So for all instances of those types, it's automatically configured and can be displayed when we need it.
When you use SQL Bridge, you need to configure it all per tag.
I think if it is possible @np7707, that you get both the tag historian and sql bridge modules. As @Sanderd17 mentioned, the historian will capture every value and display it easily. I have both and use both. The only down side to the historian is querying it. I haven’t done so myself, but I’ve seen posts on it and it is complicated due to the partitioning etc. Check out www.inductiveuniversity.com and view the videos on these modules, that will help you choose if you cannot get both.
Manually querying historical tags is indeed somewhat complicated. Though I've done it before, and it's feasible (but not pretty) if you know your way around with SQL.
But the historian also has a queryTagHistory function where the querying, simplification, interpolation, etc. is done for you (you only need to set a number of parameters). That's ofc, if you only need to query it from inside ignition.
If you need to communicate with external systems, you'll probably want to design your own schema, and the SQL bridge will be better suited for you.
Or purchase the WebDev module and make data available through web method calls.