Hello,

I need to log and calculate data from a machine, and report on top of this. Any advice is greatly appreciated...

More Info:

This will be a standalone product to be fitted to existing field machines, so cost of runtime licenses (vs. engineering and time!) will be an issue. I've done some research, but not sure which options might be the best. I am hoping for someone's advice with previous experience in this/sections of the field.

A: Programmable controller:

The controller will not be responsible for critical machine control, but more for calculations from analog, motion and digital sensors. Calculations/Data storage needs to be performed and stored at fixed 100ms intervals (Interrupt driven program). Motion feedback will probably be via Profibus/Profinet encoders. These have to be initialised/programmed when setting up the machine for operation (No "Soft" counts offset). Analogs are std. +-10V signals, and Digitals +-120/220Vac. Amount of encoders = 5. Analog = +-24 and Digitals +- 32. So there is not a lot of I/O!

B: User Interface for Operator

As most SCADA systems, when used for machine controls become extremely difficult (Small Puzzle Pieces, scripts, expressions and bit-stripping that becomes difficult to trace), I have decided to possibly go for something like the .NET languages. I need to be able to build controls that are possibly linked to OPC/DB data (Intelligent items on the touch screen, and not the normal gauges and slider controls as advertised with many suppliers). I am planning to use an OPC server, as this will be std. for all different controllers: AB, GE, MODICON... and I need to build an OPC client and possibly in same app an OPC server to distribute to several other applications that form part of the complete system (machine control). At the same time I need time be able to log the 100ms Data into a SQL/fast Read/write database.

C: Reporting System:

This system will need to replicate data locally and to a remote location, for backup, and increased DB speed when accessing the Reports. This should be something like a web-based system, but the reports should be nicely printable/e-mail. I will also need charts for the UI. Chart types with summary tables should include Pie, Line, Scatter. Realtime on UI if possible.

Questions:

a. Are there any PLC 'Bricks' or I/O controllers available for this I/O requirement? (Not using expansion modules; buying analog modules sperately becomes very expensive!?)

b. A Hard PLC (CPU) might be too expensive for the amount of processing/control - there is more calculations than actual control/setting instruments. I'm thinking of maybe using a soft PLC, as there needs to be a UI anyway (Panel PC/similar). A Soft PLC (With a Low Tag License/freeware) that can interface via a fieldbus card (Profinet/Ethernet/Modbus TCP), to remote I/O and devices. Are Soft PLC's licensed on the "Per Scan Point" principle?

I had a look at the list on http://www.control.com, but found some other versions as well. Does anyone keep an updated list or maybe recommended? Is it possible to access SQL from the user program in a Soft PLC? Logging in specified 100ms intervals, and not only using timestamping?

c. Maybe calculating (in real time?) and logging data from the UI/program directly to a DB. Logging signals from a PCI DAQ Card? Do/can these cards generate events on certain times? I don't need to log gGb/s of data, only 10s/s...

d. Can I use a SSD disk with Windows and when logging to e.g. SQL database? What is the expected lifetime of these disks, and has it been properly tested in industrial applications yet?

f. If the PC is CE based, it might be a bonus for startup, real time and operator lockdown. I am not familiar with Linux and others (yet). Does the .NET framework support "non-form" timer events (Using interrupts from HW/Motherboard timers, for precise timing?)

g. Are there any books available to learn programming in .NET for industrial applications? (Specifically for replacing SCADA systems?) Maybe sample code and or papers of a fully working application?

h. What are the reporting systems that are available, and how complex is it to configure? Are these not normally very expensive?

Many thanks to everyone in advanced for the comments/suggestions. If there is any better available options, please let me know...

 

I will address your questions first, and then comment on the application.

a) I/O Modules: Have a look at the I/O modules from Advantech or some of the other companies (there is a company whose starts with an "A" whom I can't recall, but I am sure they will chime in on this). Also have a look at the PLC networked I/O modules from Automation Direct as well as a few other vendors. I think you will find these easier than integrating a PLC "brick".

The problem with using a PLC as I/O will be long term support of the hardware. You may find the ideal PLC, but it will be replaced by a different model with different I/O in a couple of years. If you stick with I/O modules that use Modbus/TCP you will find a much greater variety from multiple suppliers.

b) Soft Logic: I can't recommend a particular stand-alone soft logic system. I'm not sure that is what you really need anyway. You are already gluing a lot of different pieces together and it is getting very complicated.

I've written a Free (GPL) soft logic library that can be incorporated directly into a PC program (it becomes part of the rest of the program). I don't know of anything else like it which is available.
(http://sourceforge.net/projects/mblogic/)

The soft logic library is the MBLogicEngine package. The version that is on SourceForge now is an older version that will be replaced in a few days with a rewritten and much improved one (I am updating the documentation before releasing it). The web site however (http://mblogic.sourceforge.net/) will show you how it works. One of the web pages shows how to use it as an embedded library. Since it is Free Software, it certainly meets your criteria for low cost.

I'm not sure if you want to use MBLogicEngine, but I think that what you need is something like this (programmable like a PLC, but can be embedded directly in another program). As I said above though, I don't know of anything else like it.

c) DAQ Board: Normally, when you use a data acquisition card you configure it to acquire data at a set rate. It then places the data into a memory buffer. In most applications, you ask the card to acquire a set amount of data and wait until it is done.

For example, you might ask for 10,000 samples at 44,000 samples per second. Your program makes a function call which configures the board and starts it acquiring. The board acquires the samples and then tells you it is done.

It is also possible in many cases to acquire data continuously. Your program then has to empty the buffer as fast as the board is filling it. Your program would in this case grab large blocks of data at regular intervals from the buffer (rather than one sample at a time).

10 samples per second however is a very slow data acquisition rate. I couldn't tell you if there are any boards readily available which can operate that slowly.

Why do you need a DAC board for this? Is it for the precise acquisition timing? For something this slow, I would recommend looking for a different solution. If you don't need the precise timing, then 10 s/sec is probably better done by just polling an industrial style analogue input module.

d) Solid State Drives: People have used solid state drives with Linux for years. The technology has now advanced to the point where it is practical to use them with MS Windows XP. It is not, however, practical at present to use them with MS Windows Vista because of the enormous size of Vista. The problem is one of capacity versus cost.

The fastest growing segment of the PC market is very small cheap laptops, many of which use SSDs. These come with Linux or MS Windows XP. The XP versions are more expensive because of the greater hardware requirements. Nobody is putting Vista on them because the hardware requirements make that uneconomic. So you can see that it is done today. It is just a matter of cost versus capacity.

However, you mentioned that you are using a database. Calculate how much storage you will need for data and be sure to allow for that. 10 samples per second continuously is 315,360,000 records per year.

f) Software: I'm not sure I would recommend MS Windows CE unless you are very familiar with it. It is more difficult to write software for (it is NOT regular MS Windows), and I don't see what the benefit would be in this application. If you are just looking for "lock down" capability, you can do this with any general purpose O/S.

I can't answer your question about DotNet, other than to point out that it is inherently incapable of being used in real time applications. If you really do need real time interrupts, then I think you need to use an RTOS and write the program in C or C++. Otherwise, try to avoid the need for high performance real time in your application.

g) Books: Writing industrial software tends to be a matter of experience and posting questions in places like this. Having said that though, I have seen a very good book, but it isn't for DotNet. "Python and Tkinter Programming" by John E Grayson is excellent. The book is actually about the Tkinter GUI library and Python, but the author's background is in writing PC software for controlling equipment. His explanations and examples are drawn from that background rather than the business applications which seem to be used in most other books.

h) Reports: For reporting, you mentioned that you want a web application. The normal software for doing something like that would be an Apache web server and PHP (or Ruby or Python) to script the reports. Charting, printing, e-mail, etc. are all straightforward. Cost is zero. If you don't want to do it yourself, there will be lots of people available wherever you are who can be contracted to write this.

To comment on your general requirements.

1) You said the program has to run on an interrupt at a fixed 100ms interval. How precisely though? That is, how much deviation from that 100msec is allowed? Can you allow for some variation provided you time stamp each sample and allow for the time differences in your calculations? If you can do that, it would greatly simplify the application. This is probably one of the key design decisions in the entire application.

2) Cost. You mentioned the importance of cost several times, but then you also mention using OPC and third party graphics libraries. These tend to be *very* expensive if you are using them in any quantity and are licensed on a per unit basis. I would suggest that you think very hard on this conflict and do some estimates to see what effect these purchased libraries have on your budget.

3) Amount of data. You are logging data at 100msec intervals (non-stop?). I think you need to figure out how much data you will be generating over the course of a year. It could be a lot, and that will have a major effect on your overall system design.

4) Speed. You've mentioned using OPC. OPC can be slow. I would suggest that you plan on spending time benchmarking a configuration before committing to it. What you many need is a communications library that you can embed directly into your application.

I don't know the details of your application, but the general outline of it sounds similar to what I am writing a platform for (see the above web site links). If I was building something like what you have described, my approach would be something like the following:

i) Programming language - Python, using the Twisted framework. Using Twisted would reduce the amount of work involved by about 2/3 to 3/4 as compared to writing everything yourself. I used Twisted as the base for the MBServer package (see the above links). It can be a client and a server simultaneously. In fact, if you look at MBServer you will see that it actually has multiple clients and multiple servers with different protocols all going simultaneously in one program. That is not easy to do properly without using something like Twisted.

ii) Database - PostgreSQL.

iii) GUI widget toolkit - You are concerned about cost, so for a conventional GUI, GTK+ or WxWidgets. As for the "industrial graphics", I would create my own where necessary, but in most cases try to stick to the standard computer GUI elements. I'm not impressed by graphics where someone spent a lot of effort making a numeric display unreadable (I've seen libraries where people simulated glare and scratches on a panel meter display).

You might also want to think about a web based display. Have a look at the MB-HMI package in the above mentioned links. The project web site does into a fair bit of detail in how to create this.

iv) Soft logic. I would use a library that could be embedded directly into the application. I don't know of any besides my own, but there may be one somewhere. It allows a user to write a PLC program (Koyo style instruction list for my library) to customise the system to a specific application without having to modify the main application software itself. The PLC program gets loaded by the main application as a data file, and then executed by just making a function call at a regular interval.

In the case of the library that I wrote, since it is open source it is pretty easy to add application specific PLC instructions (e.g. add a PLC instruction to control data logging).

v) Reporting. I would use a web based reporting system. I would build a web server directly into the application. Again, using Twisted this is straightforward, but in that case you do have to do the report scripting in Python rather than in PHP (which is how I would prefer it anyway).

vi) Communications Protocols. For any hardware that I was specifying, I would stick to a single protocol that I understood well instead of trying to support everything. I would also use a protocol that I could embed directly in the application software. My own choice would be Modus/TCP, because it is one of the few open protocols and it is fairly simple and easy to use.

The hard part would be interfacing to existing PLCs. Most PLC vendors don't like to have their stuff work with anyone else's. Going through some sort of gateway might be the best solution, depending on how tightly these PLCs need to be integrated. I definitely wouldn't want to design the entire system around the limitations of some vendor's PLC. The application is hard enough as it is without having the tail wagging the dog.

vii) Enterprise Connectivity. I'm not sure just what your application is, but I would think about whether to provide some sort of communications access for systems which don't understand industrial protocols (MRP/ERP, maintenance management systems, etc.). A REST type web service or JASON based protocol would be good fit for this.

viii) Status Monitoring/Management. A web based system status monitoring would be a good idea as well. This could provide web pages showing the current status and configuration. It could also be used to display on-line help and documentation. The web server for this would be built into the application (see above).

ix) OS - I would think about using Linux. XP will be discontinued soon (the termination date has been extended out several times already). Vista has well known problems. Windows 7 (the replacement) is unlikely to be much better. There are lots of headaches caused by the copy protection and DRM systems. Viruses and worms are a problem, and anti-virus programs are a cure that is almost as bad as the disease. Windows sounds like a lot of pain for something that you are distributing as a complete package anyway.

At the very least, I would be sure to stay away from any software or features that are MS Windows only so that I didn't paint myself into a corner on the design.

 

It seems there is not much more to add to M Griffin's extensive post. Apart from the fact that Industrial Control Design makes a software platform - Control Design Platform or CDP, which is able to meet most of your requirements. It is event-driven, can run on 1000Hz, has built-in capabilities for communicating with Modbus, built-in GUI capabilities, allows you to use Qt GUI tools, runs on Linux, RTOS-32 or WinXP, generates C++ code, can log events, alarms or data to file or SQL database and runs on standard industrial PCs.

Dependent on your real-time requirements, you may be able to implement all your logging and calculations on a single panel-pc appropriately spec'ed. If the requirements are too harsh to perform all tasks on the same hardware, you can easily split your application to run on two PCs communicating with each other over Ethernet/UDP - which is a built-in capability of the CDP middleware.

Please check out CDP on http://www.icd.no or for more specific information contact me directly on [email protected].

Best regards,

Fred Gjoertz
P.S. CDP does not require any run-time licenses and comes as a developer's package only.

 

I think the "A" company being referred to might be Acromag.

Yes, Acromag has a terrific offering of high performance, high speed,
and highly reliable Ethernet I/O products that commonly speak Ethernet
Modbus TCP/IP protocol. Density and affordability are both very high
too. For the remote i/o requirements for this application, I would
check out Acromag's EtherStax product family. Go to www dot acromag dot com and search on ES2113 (96ch DIO) and ES2161 (32ch Diff and isolated AIs).

These products update all channels in 1mS for the discretes and under
5mS for the analogs. If you're only using a small amount of analogs,
the update times can be less than 1mS.

If you're programming in C, Acromag also offers C-Libraries that compile in MS Visual C, Linux, VxWorks, QNX and even OS9 if needed. Acromag includes the source code and a demo program for learning how to frame MB TCP/IP read/write commands.

Some PLCs or controllers tend to "slow down" as you add more i/o to the rack, especially the lower cost units. So, having a distributed
Ethernet i/o system with remote i/o update times in the 1-5mS region may allow you to have an open system with faster "thru-put" speeds. Any bottlenecks in the system would likely be in the controller/HMI
scan/update times.

If any questions or I can assist, please feel free to email me at dlupo at acromag dot com.

Thanks,

Don...

 

Well, we always ask for more detail. I guess we got what we wished for this time.

"A: Programmable controller"

There's no inexpensive PLC/PAC on the market with that kind of storage and logging ability.

Rabbit (http://www.rabbit.com) might be able to pull it off. Small controllers with expandable I/O programmed in a C subset. MUCH easier than rolling your own Linux or Windows CE solution.

My immediate thought was Red Lion's Data Station. Reasonably cost effective, but a long way from free. http://www.redlion.net/Products/HumanMachineInterface/DataStationPlus.html

Rolling your own Linux solution would be next on my list, perhaps using pvbrowser or MBServer, plus other open-source solutions for things like talking to PLCs.

Windows CE, with commercial drivers, is actually the most difficult and most expensive.

"B: User Interface for Operator"

I think you're robbing Peter to pay Paul. Yes, HMI/SCADA software can be a pain. On the other hand, it takes a tremendous amount of work to get even a simplistic HMI up and running under a general purpose language. I would reconsider this approach.

Having said that, if you're going to have a full blown PC sitting there, you might as well use it for the data acquisition. I would recommend using external I/O on Ethernet, rather than PCI/PCI Express plug in boards. There are dozens of choices, but I've had pretty good luck with Wago.

"C: Reporting System:"

You have some pretty high standards. I think you will find it difficult to have a solution that is less than several thousands of dollars per system. Also, as a random guess, I'd estimate your up front development time at one man-year.

"Questions:"

"a. Are there any PLC 'Bricks' or I/O controllers available for this I/O requirement?"

Essentially, no. 24 analog points is, in fact, a lot of I/O. And I think that modular may be more cost effective than you think.

"b. Are Soft PLC's licensed on the 'Per Scan Point' principle?"

Not really. And soft PLCs are every bit as expensive as "real" PLCs. And ladder logic is useless for data logging, so why would you want that? And you have to interface your .Net code, so that's even more work. This sounds like a bad direction to me.

"Is it possible to access SQL from the user program in a Soft PLC?"

Think & Do will do this. Not sure of any others.

"c. Logging signals from a PCI DAQ Card? Do/can these cards generate events on certain times?"

Cards that will timestamp will be VERY expensive. Also, see my earlier note on internal v. external.

"d. Can I use a SSD disk with Windows and when logging to e.g. SQL database?"

Sure, no problem. As others pointed out, you probably want to boot off of a standard hard drive, but log the data to an SSD. This has the advantage that you can hot-swap out your SSDs as they fill up.

"What is the expected lifetime of these disks, and has it been properly tested in industrial applications yet?"

They last much longer than regular hard drives, and they've been used in industrial applications for many, many years.

"f. If the PC is CE based, it might be a bonus for startup, real time and operator lockdown."

Startup, not really. Real-time and lockdown, yes. But it's also a lot more work. I would recommend buying hardware pre-configured with CE, e.g. Advantech.

"I am not familiar with Linux and others (yet)."

Are you familiar with CE? Don't think, "Oh, it's Windows, so I know it." It's a completely different beast.

"Does the .NET framework support 'non-form' timer events?"

Yes. Your mileage may vary.

"g. Are there any books available to learn programming in .NET for industrial applications?"

Not really.

"h. What are the reporting systems that are available, and how complex is it to configure?"

I'm not really sure. But it sounds like a good thing to research out.

"Are these not normally very expensive?"

As compared to what? Writing it yourself? I PROMISE it's more expensive to write it yourself.

"If there are any better available options, please let me know..."

Red Lion would be my first stop. It's an off-the-shelf solution. Always look for COTS when you can get it. (This from a guy who makes his living doing custom systems.)

If you really want to do things yourself, MBServer and pvbrowser is a good place to start to see what it took other people to accomplish a similar task.

-James Ingraham
Sage Automation, Inc.

 

In reply to James Ingraham: I don't have any argument with most of what you had to say, but there are a few points I would differ on.

I believe the original post mentioned the project involved multiple units, and so the engineering man hours versus purchased item cost balance is a bit different than for a single unit project. A custom HMI screen wouldn't be too hard, especially as he stated the system is fairly small. I think that by the time he force fit a SCADA system into his application (or vice versa), the custom approach would be simpler. If it actually were a large one-off SCADA application, then it would be a very different story.

The correct balance for this decision depends on how many units are involved versus the complexity of the application versus... a lot of other factors. There is probably no way to come up with the "right" answer to this without being the actual system designer.

As for solid state drives, I would just use one drive, unless the amount of data being logged is very large. If you had both an SSD and a conventional drive, the system is going to crash anyway if either drive fails, so there's not any reliability to be gained by using both kinds.

An 8 GB SSD is not much more money than a 250 GB conventional drive. You can get larger drives, but you'll pay more, of course. The critical number is how much data is being generated. If you are generating 2 kbytes per minute of data, that comes out to about a GB per year.

As well as space for the data, it needs space for the OS and application. For the application software that I mentioned, the disk space taken by the application itself will be negligible. The size of the OS will be what matters. For Linux, it would be less than 1GB (for a distro with everything plus the kitchen sink). For Vista, it won't fit at all. For XP, it will be somewhere in between. So if you are using Windows, you can still do it, but you have to be prepared to pay more for larger hardware. In either case, be sure to put lots of RAM in so the system never needs to use the swap space.

The reporting system was described as being "something like a web-based system". If you are using what most people use, (Apache plus MySQL or PostgreSQL plus PHP or Python or Ruby), then software license cost is zero.

I'm not sure where you get the one man year figure from. If you take a PHP class, making a web based report is usually a single homework assignment. At the end of the course, doing a web based report will be one of the exam questions. If you need security for a public facing web site, then that's when things get hard. That sort of thing is hard no matter what software you use, though.

You can get report generator software, but the ones that I've heard of take *more* work and a lot more time learning how to use them than just doing it conventionally. Any book store that has a computer section will have shelves full of books on PHP. This how people write run of the mill custom business applications these days. This is why they don't use VB anymore.

 

Yes, Acromag was who I was trying to think of. To make it clear however, I was suggesting looking at their products, it wasn't a recommendation. They don't allow you to download the manuals from their web site (they only have catalog information), so I can't tell if any of them are actually suitable for the application.

I did notice that the analog module has a 3 Hz cut-off, which is much too slow for this. There is another analog module, but no cut-off filter specs (perhaps that is in the manual).

You said 1 to 5 ms to update the channels. Is that the time to respond to a message request, or is that just the internal conversion time?

 

M Griffin: "...the engineering man hours versus purchased item cost balance is a bit different than for a single unit... The correct balance for this decision depends on how many units are involved versus the complexity of the application..."

True.

M Griffin: "A custom HMI screen wouldn't be too hard..."

I came into automation from a CS/IT background. Within a few months of starting this job I was writing custom HMI screens. However, I was apprenticed to people who knew what they were doing, and we had a heck of a middleware stack for interfacing to hardware. Now it takes about a week.

About three years later I built some screens using Rockwell's RSView32 HMI system. It took about a month. It takes about a week now, because we've built up a library of applications to copy from.

M Griffin (paraphrased): "[Report generator software takes *more* work than just doing it conventionally.]"

I'll have to defer to your experience on that.

M Griffin: "There is probably no way to come up with the 'right' answer to this without being the actual system designer."

Or even if you are. There are always trade-offs. Admittedly, I have a bias towards one-off thinking, since that's what my company does. We've done custom and COTS, and right now we lean a lot more towards COTS. That information and $3.50 will buy you a coffee.

M Griffin: "If you had both an SSD and a conventional drive, the system is going to crash anyway if either drive fails..."

Good point. I was thinking about the reliability of the DATA, not the reliability of the SYSTEM. So yeah, probably not the best idea.

M Griffin: "If you [use LAMP then software license cost is zero."

True. And these days it's pretty easy to configure and maintain.

M Griffin: "I'm not sure where you get the one man year figure from."

Well, all time estimates are basically pulled out of... er... the air. But I stand by it as a rough estimate.

"If you take a PHP class, making a web based report is usually a single homework assignment. At the end of the course..."

Okay, there's four months of the year sitting in a PHP class. But seriously, learning a language (which is what it looks like he's doing) slows you down a lot. He hasn't even PICKED a language yet. We're a LONG way from shippable code.

Let's look at what he wanted again:
machinecontroller: "analog, motion and digital sensors... replicate data locally and to a remote location... web-based system... reports should be nicely printable/e-mail... [Realtime] charts for the UI... [including] Pie, Line, Scatter... [communication via OPC servers to] all different controllers: [e.g.] AB, GE, MODICON"

And it needs to be a shippable, production system that the developer does not have direct access to in order to tweak as needed.

This is NOT a weekend project.

-James Ingraham

 

Hello,

You should be able to download Acromag manuals from the website by
navigating to the datasheet page. If not or you would like them
emailed, just email a note to [email protected].

Here are some benchmarks on the ES2161 or ES2162 32ch current/voltage
analog input performance. They update all 32 analog input channels in
5mS or less if you're scanning a smaller group of channels. This timing would be the internal conversion time. The corner frequency on the analog inputs is greater than 10Khz. Per channel filtering can be changed, if needed, through the use of low or high band-width 8B/7B type signal conditioners.

For Ethernet response times, if you do a low-level ping test on the
units, you'll find a 1mS response time. Moreover, if you do a block
read on all 32 analog input channels, it should take approximately 2-3mS to get all the data back across an open network.

Does this help?

If any questions, please feel free to email me.

Thanks,

Don Lupo
dlupo at acromag. com

 

In reply to James Ingraham: With regards to the web based reporting, I didn't mean to imply that an entire system could be tossed together in a few hours. A man-year though is really excessive. It's hard to put a figure on anything when we don't know what the system has to do, but a simple system shouldn't take an experienced person more than a few weeks. More features would take more time. The reports themselves are the easy part (which is why integrating drag and drop report generators can actually make the overall system more difficult). The big unknown is how many bells and whistles the bike-shed committee will want to add to it.

One of the reasons that I suggested a conventional LAMP type system was that he could subcontract that part of the system to someone else quite readily. There are lots of people who can do that kind of work. If he wants to maintain it himself after it is done, then he could take a PHP course and learn enough to modify a working system. As it is though, it sounds like a piece of the project which can be readily split off and given to someone else.

As for the custom HMI screens, they're just screens. He isn't actually making a real SCADA system. He is just putting screens on the front of what is otherwise a custom program (section B in his post). I think that grafting something like WinCC onto the program that actually runs the system sounds like doing things the hard way. I'm making some assumptions about the system design, but that is my impression of it.

As for one-off systems versus multiple units, there are different design trade-offs in each case. For multiple units, it is a lot more important that you have something that is maintainable over the long run. The worst maintainability problems come from using subsystems that are critical to the design but which you don't have control over. When you can't get that part or software module any more, you have to modify some of the systems to accommodate an incompatible replacement, and now you have two different systems to maintain instead of one. If that happens too many times, the whole thing degenerates into a bunch of one-off systems and the economics of the design go right down the drain.

For a system that is intended to be one-off, that isn't a concern. The design and changes are budgeted for that one machine and everyone knows that. If you want to change the program or drawings for that one machine, you don't have to worry about how it affects any other machines. If a new software version runs OK on that one machine, you're done. You don't have to test and validate it for different hardware combinations.

The project sounds like an interesting one (which no doubt is why we are spending so much time talking about it). It certainly sounds "challenging" at least. I wouldn't want to venture a guess at a time scale though, as I don't know enough about it.

 

Hello,

If you opt to use OPC DA, you may take a look at our PlantStreamer package. It does data acquisition via OPC DA and stores the data in a Postgresql database. PlantStreamer is open-source (GPL).

Regarding the reporting, we have an apache+php+postgresql(+tomcat) solution and we would be very glad to customize it for you. Thank you.

With Best Regards,
Andrey Romanenko
Ciengis - Advanced Process Control
andrey (at) ciengis (dot) com

 

Hello,
Thank you so much for the replies, I am currently investigating all the possible and mentioned options available. And a big thank you to everyone for producing the free and open source software, frameworks and information. Although I am not a very active participant/user in this (probably too scared of new/unknown technologies), I do have the greatest respect.

Controller Options:

I think it is obvious that I can safely remove the Brick and Datacard options (lots of wiring to the PC!), and go for something like the Acromag or Wago distributed I/O modules. The PCB (Rabbit) Modules are nice, but not always accepted by a customer (off the shelf Products are more acceptable)

To some extend I am not actually willing to pay the price for a commercially available Controller/CPU Module, as this will not be controlling anything, but acquiring data and performing averages from this and/or final calculations. A Hardware Module will also not have the space/memory available for Datalogging.

Logging Rate:

The 100ms (or similar fixed rate) is something that will be very nice for me to have, as I will be able to perform e.g. 1 sec averages and realtime playback functionality from this (without queries to the DTS Database fields).
But if this is not possible at all, I will have to find a workaround.

That was basically the main reason for the Soft PLC - Interrupt driven (100ms), with a storage buffer to Async (if needed) transfer the Data to SQL.

I have seen a product called opcdbgateway, and was wondering if anyone is familiar with it. Apart from OPC Client and OPC Server, it looks like it also has a embedded Soft controller?

Communications:

Yes, some OPC servers like Siemens are slower for DA, and comes with huge installation and config requirements. The Softing Option is quite quick (Not sure which one is Actually the quickest), and I was thinking that for Ethernet 100ms would be reachable. Also OPC is a Std interface to different controllers, although Modbus TCP is also nice! New WinCC Flex Advanced has quick update rates as well.

User Interface:

I thought that C# would be the easiest language to learn (given the time and personal interest), and if I use a SCADA, it will definitely be only as a combo Soft controller and HMI in One. Will then need some ActiveX controls though! The price for feautures that I will be using and RT licences are not economical enough.

C/C++ is a better option for performance, but maybe .NET might be more acceptable/supported/required in future. The Graphical designer will probably reduce time to develop, with nicer (and readible) eye friendly graphics. Will need a way how to map/bind opc data to customised controls though..

Logging:

The 10Hz samples will most probably be stored in a sort of temp file/db for playback and be flushed/cleared occasionally/daily. This data is what will also be used to calculate the final sequencial rows in the Database.

The reason for CE was basically to get away from XP (Especially new SP3 OEM!) and defintely Vista/futures.

As I am not familiar with Linux etc, I also thought that this will probably be easier maintainable by other persons. I know that the newer versions are more user friendly, but I am just trying to decrease the amount of knowledge to learn and to pass on; to e.g. reinstall a PC/machine if it fails.
Ask someone to e.g. log into a OS they don't know and watch what happens - people are scared of new things. I will get it running smoothly, and when (not if) the PC starts with its problems, I will be there again...Some people are even scared and don't know about cloning/ghosting and restoring...

So first Price is obviously a Installer/Install Shield, with all configuration included (No tweaking afterwards)

Storage Solutions:

Again I have nothing about the Open source Databases available, and probably don't know best, but I was thinking of using MSSQL (As I have used this before (not via programming), and that its probably a widely known DB Server - I have to keep the system Open for the final client)

I think that this might be a medium project (and interesting!), so I will have to make some trade off between custom and commercial products. Pre developed custom solutions that I can use will hopefully increase time to market.

Thanks again for the knowledgable replies

 

My replies are interspersed with your comments:

>Logging Rate:
>The 100ms (or similar fixed rate) is something
>that will be very nice for me to have, as I
>will be able to perform e.g. 1 sec averages
>and realtime playback functionality from this
>(without queries to the DTS Database fields).
>But if this is not possible at all, I
>will have to find a workaround.

100ms should be quite possible, provided that your I/O hardware and protocol drivers will permit this. I/O hardware can in many cases turn around a poll request in 1 or 2 milliseconds. You have to check how the specific hardware you are looking at though will behave. Sometimes the manufacturer will not publish this information and some hardware is quite slow. I have worked with models that had an average response of 1.5 ms, and I believe that an Acromag rep has already replied that their hardware will do 2 ms (you need to confirm this though).

For protocol drivers and application software, it depends on the software and OS.

For software timing and repeatability, see the previous discussion we had here beginning on 10 November, 2004 "Ways to do machine control under Windows" http://www.control.com/thread/1026202809

>Communications:
>Yes, some OPC servers like Siemens are
>slower for DA, and comes with huge
>installation and config requirements.
>The Softing Option is quite quick (Not
>sure which one is Actually the
>quickest), and I was thinking that for
>Ethernet 100ms would be reachable.

I would consider an average of 100ms very easy. The question is 100ms +/- what percent?

The time the software itself should take to create and send a poll request should be in the microseconds. OPC is often slow for reasons that have nothing to do with the actual communications.

>Also OPC is a Std interface to different controllers>

Not exactly. OPC is an interface between application software and OPC drivers. The actual communications to the controllers is in the normal industrial protocols (e.g. Modbus/TCP).

>User Interface:
>I thought that C# would be the easiest language
>to learn (given the time and personal interest),

I wouldn't consider C# or Java (C# is just a knock-off of Java) to be easy to learn. There seem to be a lot of magic incantations that have to be performed to get them to do anything. They aren't much different than C or C++ in that respect. Personally, I prefer Python, but I suppose that is another discussion.

>C/C++ is a better option for
>performance, but maybe .NET might be
>more acceptable/supported/required in
>future.

Knowing the C# language is not the same as knowing DotNet. DotNet is the set of class libraries which Microsoft sells with C#. The C# language is not changing that rapidly (although new features are added on a regular basis). DotNet though seems to be undergoing a steady churn every 12 to 18 months. A DotNet 1.0 program is not necessarily compatible with a DotNet 4.0 installation. Furthermore, a lot of the useful stuff isn't in the standard installations, so people can end up having to install several hundred mega-bytes of extra libraries just to get even a simple application working.

I won't claim to be an expert in this area, but I think that if you are looking for a stable platform then Java seems to have a lot less churn or change for the sake of change. I'm not sure I would pick C# or Java, but if I had to pick one based on your criteria, I would pick Java.

I would suggest that you draw up a list of what you are going to need to implement the project and see what languages can fit that list. When you list a third party automation library, then I would suggest testing it to see if it really does what you hope it does. That might be hard to do if you have to buy it first. However, a lot of the specialised stuff is actually somewhat disappointing once you get familiar with it.

>The Graphical designer will probably reduce time to develop, with
>nicer (and readible) eye friendly graphics.>

There are lots of GUI designers. Most work with multiple languages. GUI designers are not used as much as you might think though. Once you are familiar with write GUI applications, it is actually a lot faster and easier to simply write the GUI code (most of it is just cut and paste with a few variables changed) provided the library itself is any good.

>Will need a way how to map/bind opc data to customised controls though.>

I think that would be doing things the hard way. There is no need to make ActiveX controls and link them to OPC through a remote procedure call. Just call the GUI widgets through a library call, and use the appropriate library call to send the data to them. The only reason that people sell ActiveX "controls" that way is because it's the only way they can sell them to you without giving you source code. It's actually a very round-about way of doing things. If you are making your GUI from standard widgets, or doing standard drawing calls, then you don't need to bother with such a convoluted way of doing things.

<clip>
>The reason for CE was basically to get
>away from XP (Especially new SP3 OEM!)
>and defintely Vista/futures.
>
>As I am not familiar with Linux etc, I
>also thought that this will probably be
>easier maintainable by other persons. I
>know that the newer versions are more
>user friendly, but I am just trying to
>decrease the amount of knowledge to
>learn and to pass on; to e.g. reinstall
>a PC/machine if it fails.

So you want to use Windows CE because you think that Windows XP and Vista (and 7) are going to be a problem. On the other hand you want to use Windows because you think that people will know how to re-install it. I'll start by saying that people will have no clue on how to install Windows CE. It's a non-trivial task. I wouldn't want to do it myself.

>Ask someone to e.g. log into a OS they
>don't know and watch what happens -
>people are scared of new things.
<clip>

I think you will find out that very few people really know anything about Windows. Most people know how to click on a few icons, but that's about it.

I'll put things another way. What OS today has the reputation for being the easiest to use, the least intimidating, and "just works". It isn't MS Windows. Most people would say Mac OS/X. Yet it's nothing like Windows. If you look down into the guts of it, it is a lot like Linux. In fact, Linux and Mac OS/X share some of the same internals (e.g. the printing system). The main technical difference between the two is the GUI and the fact that Linux runs on a lot more types of hardware. So how do all these Mac fanatics who like to brag that they know nothing about computers manage to get by from day to day using a fully fledged Unix OS with all that scary stuff under the hood? They seem to manage.

>So first Price is obviously a Installer/Install
>Shield, with all configuration included (No
>tweaking afterwards)

I hope you'll forgive me if I say I'm not impressed by "Installshield". Package management is something that Windows does rather poorly. Actually, it doesn't really do it at all.

For typical Linux distros, you build a "deb" or "rpm" file and let the distro's standard package management system take care of everything. If your application says it needs a certain database, the package manager figures out if it's already installed and if not it finds the database and installs it. If the database in turn needs something, the package manager installs that as well.

When it comes to ease of installation though, you won't beat having everything (OS, application, drivers, etc.) all on on CD with one integrated installer that just does everything automatically. I don't know how you would do that with MS Windows, but it's how a Linux distro works. Most of what is on a Linux CD isn't Linux itself. It's the application software, drivers, and configurations. You put the disk in, answer a couple of questions, walk away, and 20 minutes later the system is ready to use.

Some distros have methods for basing your own custom version off their standard base. Debian calls this a "pure blend", and Fedora calls it a "spin". It's not a "fork" or different distro. It's a specialised version of their standard distro targeted at a specific interest group.

If I was trying to make an appliance type system, I would seriously look at basing it on a "pure blend" or "spin" with the addition of my own software. That way I would know that every bit of software they were running was software they got directly from me, and not have to worry about now "MS Vista Super Pro Media French Version (SP2)" differed from whatever it was that I had installed on my own computer.

>Storage Solutions:
>Again I have nothing about the Open
>source Databases available, and probably
>don't know best, but I was thinking of
>using MSSQL (As I have used this before
>(not via programming), and that its
>probably a widely known DB Server - I
>have to keep the system Open for the
>final client)

If the database is part of your system and the customer has to care about which database you are using, you're doomed. The average automation person has a vague idea of what a database is (it's some place you store data), but they have no idea about how they work or how to fix them.

If you want a simple database that is embedded in your application, have a look at SQLLite. It is embedded, so it's not a solution if multiple applications need concurrent access. It also runs out of steam when it gets really large. However, it is probably going to be the most maintenance free solution you can come up with.

For a really large database, have a look at PostgreSQL. It is modelled after Oracle (or it might be the other way around, I don't recall the history), so people with Oracle experience may understand it better.

If you want something like MS-SQL Server, then there is another database that is similar to it. I don't recall the name of it at the moment, but I could look it up if you are interested. It's not free, but their licensing cost is usually a lot less than what Microsoft charges. MS SQL Server is actually just an OEM'd version of this other company's product, with some third party products (e.g. from Veritas) added and some additional integration and tweaks from Microsoft.

If you are going to use MS SQL Server, read over the licenses with a fine tooth comb and possibly consult a license expert (which nobody here is) as well. License costs can easily go from next to nothing to many thousands of dollars per server depending on how you are using it. We have had a number of posts in this forum where someone has asked how to connect to the MS SQL Server database that a major automation company has used as part of their product, only to have a rep from that company chime in to say they have to buy a license from Microsoft before they can legally do that.

To sum up, I would suggest that you put a design down on paper and figure out what bits and pieces you are going to need for that design. You've mentioned cost a couple of times, but then also said you were planning to use some rather expensive third party software. I think you will be in for a bit of sticker shock once you put a software BOM together. At that point you will be going back to the drawing board to come up with a new software design that fits your budget. I think you should do that now, rather that do it half way through the project when you have to throw out several months worth of work.