I would like to know if it is possible to run the
IGNITION Gateway, OPC Server, MYSQL on the same machin,
We are doing a project for one of our mill upgradation project
Metals manufacturing unit, Continous manufacturing HOT Rebar Rolling Mill, with 16 Stands
and Wire Rod Block Coil Mill,
our application has more than 1000 I/O’s,
I have to log over 100+ I/Os at every second,
around 30 DC motors * 3 (1 current feedback + 1 speed feedback + 1 speed reference) = 90 Tags
other process tags, such as loop scanners , hmds, shears and much more
so thats about 100 * 60 seconds * 60 minutes * 24 hours * 30 days = 259,200,000
thats a huge data, 100 coloumns and 259 million rows,
I am afraid of the Table Size limitation and slow response of the system,
can you please advise me, if I can run the MYSQL??
and If I can Can I run MYSQL, MAkitron OPC and IGNITION GATEWAY ON SAME MAchine,
Can you advice me the hardware system requirements as well,
kindly not the needful,
Abdul
Automation Engineer,
AL TUWAIRQ HOLDING
AL ITTEFAQ STEEL
Dammam, SAUDI ARABIA robin.abdul@gmail.com
Yes, you can certainly run MySQL, and you can certainly run the Ignition Gateway, the OPC server, and MySQL all on the same machine.
I would get a server-class machine - probably a quad-core processor and 4-8GB ram, with fast hard drives, preferrably in a Raid 1 or Raid 0+1 setup.
As far as the logging goes, MySQL can handle it. Plus, if you use the SQLTags historian feature, it will only log tags as they change, which will probably cut down on your row count significantly.
Or, you could use a big Historical Transaction group to log all 100 tags in a single, wide row. That would reduce the number of rows by a factor of 100, although the total storage would be the same because you’d have 100 columns.
For what its worth, let me add the following comments. 1000 Tags and logging 100 points once per second isn’t much. In my experience a desktop machine can handle far more than that. But I would recommend you just download and try it out. Won’t take long to set up and you can reset the 2hr runtime forever.
It also depends on how many clients you are going to launch from Ignition.
Just setup a quick sample project. Only takes about two minutes to install, two minutes to configure a PLC device and database, then look at the CPU usage. But like I mentioned before, you’d be amazed what you can do with just a desktop machine.
You’ll have no problem achieving a 1 second resolution with 100 changing tags. I’d recommend using SQLTags History with a reasonable deadband set for your application.
We’re working on a new set of SQLTags History benchmarks. In the meantime, download the software and try it for free on a desktop computer. I think you’ll be impressed with the results. You can request a 30 day trial key for the data logging, instead of going 2 hours at a time.
The older FactoryPMI benchmarks from 2008 are still somewhat relevant, available here (follow the White Paper link on the middle of the page).
MySQL does not have a table size limit, the operating system does. On a FAT32 file system (which is the best you get with Windows XP), you have a 4 gig table limit. With NTFS you get 2TB.
Try SQLTags History. It will use much less data than you expect. The demo in the middle of the Ignition release shows how to set it up. The video is available here.
[quote=“shechtman”]For what its worth, let me add the following comments. 1000 Tags and logging 100 points once per second isn’t much. In my experience a desktop machine can handle far more than that. But I would recommend you just download and try it out. Won’t take long to set up and you can reset the 2hr runtime forever.
It also depends on how many clients you are going to launch from Ignition.
Just setup a quick sample project. Only takes about two minutes to install, two minutes to configure a PLC device and database, then look at the CPU usage. But like I mentioned before, you’d be amazed what you can do with just a desktop machine.[/quote]
For my FPMI/FSQL evaluation, I actually used my desktop running vista business, logging approximately 20 data points once per second. I was then deleting old data but still had about 40,000 rows (which is pocket change really) . While running this, however, I never noticed any loss in performance. I actually forgot that I had it running most of the time.
MySQL will handle this no problem. I would recommend running a server class computer with either Server 2008 R2 or a flavor of Linux. In my experiences, MySQL works better in Linux however. Also, MySQL loves RAM, so the move the better. You might want to do a case study of MyISAM vs InnoDB vs InnoDB 1.04+ vs Archive tables types and see what works best for you.
Using Historical SQLTags will work very well here, as it automagically partitions your data into new tables every so often. This reduces your working data set, and prevents performance loss.
Finally, make sure your storage subsystem can handle the amount of requests you need. I would say you would want atleast a RAID 1, probably 0+1, using 15K SAS drives. Another option would be to use Fusion-IO cards, and while they look expensive, building a 4 drive SAS raid with controller would probably cost about the same or more. Nothing will touch the Fusion-IO card when it comes to throughput or IO count.
You can also use partitioning which is an inbuilt feature in later MySQL releases to split up data across multiple backend tables etc.
I am actually using another SCADA system (Adroit to be exact) logging to a database. Because I don’t trust the machine computer with the data and do not trust the network to be functional 100% of the time to connect to a remote database (can’t have machine downtime for a network issue), I use a custom program which reads data off the SCADA unit and inserts it into the business intelligence system (which is a pure Java object oriented database system, db4o to be exact). Works fantastic and allows us to run a very lean MySQL configuration on the SCADA systems. Other benefits in this case is that db4o cannot be worked with directly from that particular SCADA system so I need to use an ODBC capable system in the middle. This is where Inductive Automation solutions, being Java will help.
I always used NTFS with my Windows XP boxes...