I don't think there's anything wrong with the basic idea or PC control in general, but you would want much more robust software. And unless it was very efficient software, more horsepower would be handy to have.  We still need a good Open PLC class hardware platform to build on.  I'm surprised some of the newcomers trying to claw their way into the market haven't tried an Open approach. It would have better chances than more of the same closed, expensive, BS.

Regards
cww

 

That's why the fanless all in one mini systems available recently are so interesting. With a flash disk, you can have DC powered, no moving parts, low power DIN rail mountable system that will run any reasonable PC program and has good connectivity and lots of HP compared to PLC offerings, all OTS and at very low cost for capability. I would like a PLC type box for the cheap local IO, but one of these and a bunch of Wago/Beckhoff racks, for example, could handle some pretty large applications. Certainly into the "large" PLC catagory.

Regards

cww

 

I also looked at this a few years ago. In the end it look to me like a good entertainment option, but the platform without software loaded was too expensive to compete with commodity hardware.

The only reason for it to work would be to go head to head against commodity hardware, and in the commodities market price is all that matters.

If you were looking to build a "new" PLC platform this isn't the place to start.

MB
--
Michael Batchelor
www.IndustrialInformatics.com

 

Folks, what the original poster (Jeff) failed to mention is that we (being the other staff) already have an example of implementation: a small-scale water treatment system and fish hatchery controlled with WinPLCs and Phoenix Contact’s Think-N-Do software (formerly Entivity Studio). WinPLCs serve to execute the control logic, and a PC (connected by Ethernet) doubles as both HMI screen for operators and as a programming platform (requiring reloading of control logic onto the WinPLCs if changes are made). In 4 years of operation, we have never had a Windows CE system crash (how foolish is that?) – other than from inappropriate use by operators (storing excessive data from field instruments in the flash memory) or power fluctuations (requiring all equipment to be rebooted). This system was a fraction of the cost of traditional PLC hardware and software, very stable and reliable, and incredibly easy to learn – the flow-based programming is an asset, and certainly not a detriment. It would indeed take a systems integrator with more than 1 or 2 functional neurons LESS time to program a flow chart for process control than to write from scratch in relay ladder logic. It is certainly easier for non-programmers to understand, implement, and troubleshoot during operations. There are more examples in industry of successful implementation of TND and WinPLC for process control: HP’s (Agilent Tech.) R&D campus in Santa Rosa, CA, microbreweries in both California and Alaska, water wastewater treatment plants in Germany and the US, and metal finishing industries, and handful of others, to name a few. If you truly want to lean more, see:

http://www.automationnotebook.com/AppStories/usersolutionsappstories.html

Control in the fish hatchery setting is not all that complicated – the fish husbandry is more complex than the process control. Much of modern hatchery equipment comes with integrated controllers, where a distributed control and network system is ideal to monitor and optimize performance. The basic things that are controlled in hatchery setting include timers, pumps, and automated valves (using simple PID loops to control temperature and water flow via pump speed with VFDs). Most other things are simply monitored and alarmed (water chemistry and water levels). WinPLCs and the TND program are more than adequate for such applications.

Whether or not this whole system is suitable for a larger-scale fish hatchery rearing multiple species is a loaded question. It is true the TND software is not well known, requires specific hardware that has limited sales distribution, and comes from a smaller manufacturer with fewer third-party support options. However, larger consultants also have relationships with the big-name control system manufacturers and distributors, where they stand to lose money if they have to step outside their comfort zone for new hardware, or have staff learn a new software program for a client. We’ve demonstrated success, at least on a small scale, and have every reason to believe it can be scaled up to something larger.

For more information about our application, feel free to contact me off this post.

 

Jeff,

I think what is getting lost here is who is your user and under what conditions will the control platform run? PLCs are great for almost any industrial controls engineer and work great is a wide range of environmnents. But if the controls are indoors in a protected environment (even if it's 0 degrees outside) and the person using it does not know the first thing about ladder logic, then you have more options. Especially if flowchart progamming is used because it it more intuitive for operators who are not controls engineers. Ladder, however, is a more universally accepted progamming language for operators that have PLC experience.

PLCs might be the safe choice, but PC-based control has established enough runtime and customer base to warrant a serious look. The open platform concept simply cannot be beat either. PLCs are notorious for trapping users on proprietary networks and expensive support contracts.

PLC and PC-Based Control Vendor

 

Yeah, it's kinda strange considering how they price the rest of their gear. Any high volume SOC is going to beat any low volume SBC, but a lot of people seem to want to prove they can build a PC. At this point, there really isn't much point in building the core, but the "add a bus" thing for low cost IO is still attractive. It's a shame there seems to be a fairly large minimum cost for the hardware to run a TCP/IP or UDP stack to take advantage of cheap ethernet. I could live with no backplane IO if Ethernet IO wasn't so spendy. Of course, if space is not an issue you can use an old PC. :^)

Regards

cww

 

I would only ask: What you can possibly
consider open about such a system?
Running shrinkwrap binaries on a closed OS?

Regards

cww

 

PC 104 has always intrigued me, as well. I spend a fair amount of time discussing a project with a guy to port a proprietary TCP/IP stack to for him. He was interested in manufacturing some kind of system that never came to market.

I don't know, but it seems to me that this, or at least something like it, is probably the basis of the fanless systems on the market now.

MB
--
Michael Batchelor
www.IndustrialInformatics.com

Industrial Informatics, Inc.
3281 Associate Dr.
N. Charleston, SC 29418

843-329-0342 x111 Voice
843-412-2692 Cell
843-329-0343 FAX

 

In reply to Michael Batchelor: Most PC/104 vendors offer a free Linux port for their boards. That is the most practical way to get a TCP/IP stack for them.

PC/104 boards are usually very limited in terms of RAM or flash. This means the Linux build is an "embedded" type rather than a desktop build. That usually means things like Busybox instead of BASH, no graphics, etc. If you are developing software for them, you are doing embedded style programming.

If you are looking for fanless PC systems, look at things like mini-ITX (and nano, pico, etc.). Mini-ITX is 17 cm x 17 cm. Several vendors sell in this board format, with VIA being the biggest. A number of vendors are also selling similar systems in various proprietary small form factor board formats. They have fanless versions (as well as faster versions with fans), and various options for booting from flash. They are usually full featured 32 bit PCs, although with slower CPUs (to cut size and heat output).

The fanless systems you see on the market for things like entertainment systems, kiosks, POS, etc. are usually these small form factor PCs. Motherboard prices start at about $150 (including CPU, but excluding RAM).

 

I agree, particularly in theory - that's why I stressed the clunky part being Windows CE, not a PC.

There are lots of reasons why PC based controls would be better. I like the idea of an open approach as well.

I was trying to focus a response around actual implementations. An E Machine just isn't suited for industrial apps - the fans and the power supply, non-shock mounted mechanical hard drive, needs to be resilient hard reboots, etc, etc.

An industrial PC could certainly be made from commercial off the shelf hardware. It could be the best, easiest to use, most powerful and stable device ever, that could be modified at runtime - superior to PLCs in every way. Unfortunately nobody makes that software yet.

----
Nathan Boeger
Inductive Automation
Total SCADA Freedom

 

If you have a method to flash a new bootloader
and a candidate boot loader to install, then I
have a WinPLC that I can loan. I'll even help
you with the project. Your first, and perhaps
most difficult step will be to install a boot
loader that can find the kernel, load to RAM,
and start execution, all preferably logged to
the RS-232 port. From there on, the port is
straight forward.

 

I wouldn't go so far as to say nobody. We don't have a strong vertical that can provide a complete easy to use package. The problem isn't the technology, it's that everyone goes for the monopoly market rather than grow an alternative market. Things change so slowly in automation that even the perfect product you mention could only gradually filter in, and that's not what people want in a new product launch. It's far easier to just do more of the same, no matter how bad that is. That's why monopolies tend to stay monopolies.

Regards
cww

 

I haven't looked at it for quite a while but I'll poke around the Linux sites. I forget what platform the H port was for. Also, Host might help with a very limited scope first step if it were presented right. At least a little carnal knowledge would be required. A fixed address bare bones bootloader might be doable with all the embedded Linux info available. Handling the flash is kinda touchy. Hard to recover if you screw up. As soon as I get some time...

Regards
cww

 

All,

I posted my question and promptly left town on a trip. I was amazed to return and find so many replies. Thank you all for your varied and sometimes colorful responses.

At this time we have chosen to stay with industry standard PLC systems. While the WinPLC concept apparently holds significant potential there is such a limited track record that it would be imprudent for us to head in that direction.

Thanks again to everyone who responded to my inquiry.

Happy Holidays,

Jeff

 

And again, we maintain that there is indeed an abundant and varied track record and history to successful use of the WinPLC system for industrial control. All you need to do is simply look at it...
And it is neither imprudent nor impractical to embrace such a system, particularly when a successful identical application to what's planned has already been demonstrated.

But Happy Holidays, nonetheless...

 

There seem to be two assumptions appearing throughout this thread.

1 - PCs crash routinely

2 - PLCs have to be programmed in ladder logic

We have been installing off-the-shelf PCs in industrial applications for more than a decade. It is made clear to all staff that no, you don't use these PC's for games, DVDs, word processing, or any other entertainment. They are a mission critical corporate asset and are to be treated as such. Using Windows 3.1, 95, 2000 and XP with VB applications we have never experienced problems with PCs spontaneously crashing in the field when they are left to do what they were programmed and tested for.

Since ladder logic programming requires a different mindset from VB or C programming, we have chosen to develop PLC applications for our customers using the IEC languages. In particular using Structured Text (Pascal like) and Function Block Diagrams (graphic design). A VB or C programmer can be cross trained in these two languages far more easily than in ladder logic. Many routines are easier to program and read in FBD than in VB or C. If you are looking for non-ladder logic standards, this is the way to go.

Victor Robert
Key Concepts LLC
[email protected]

 

We happen to have several WinPLCs that could be released to someone serious about a Linux port. If you have a flash method and bootloader plan, I think I could persuade the Powers That Be to release them. Contact me via email as bbaker at priefert.

 

Victor - respectfully,

1. PCs do crash routinely compared to PLCs. They are not designed to handle: unanticipated shutdowns, mechanical vibration, heat, etc. They have way more moving parts. If the fan in your power supply gets dirty it will eventually seize - killing the machine. There are too many specific examples to list. PCs are also most often connected to your industrial I/O via some sort of network that can go down. This opens up another can of potential problems that a PLC connected to a backplane connected to I/O modules doesn't have.

Mission critical corporate asset or not, Windows boxes lose their reliability over the years. What kind of maintenance do you ever have to perform on a PLC?

2. The difference between implementing your PLC program in: ladder, C, assembly, block diagrams, flowcharts, etc. is of little consequence here.

The most obvious issue was the size of OP's project versus what the CE based WinPLC was designed for. After all, this is one of the most complex fish hatcheries ever to be built in North America.

----
Nathan Boeger
http://www.inductiveautomation.com
"Total SCADA Freedom"

 

In reply to Victor Robert: You used MS Windows 95 in control applications and "never experienced problems with PCs spontaneously crashing in the field"? That's amazing considering that MS Windows 95 had an overflow bug that caused it to "spontaneously crash" every month or so unless it was rebooted first. It took a few years for people to figure out what was happening, as it being MS Windows 95 few people were able to keep it going even that long.

As for there being assumptions "throughout this thread" that PCs are inherently unreliable, I think you will find that a few people were saying that PCs can be reliable provided you use hardware and software selected for their reliability.

 

Hi,

A PLC is a means of bullet proof automation. That's its job.

SCADA is a means of non-technical staff to watch and possibly affect the process environment, e.g. Supervisory Control And Data Acquistion. That's its job.

A PC is a thing to type letters on a few hours a day and then play cards. It will go down at some stage and you will lose some SCADA historicals, your proccess should not be affected. What do you expect from a $1.99 control solution? That's its job.