[Holly Gates]

Hello all, I was hoping you could offer some thoughts on selecting a PLC. I'm working at a solar cell startup where we are working on new processes for silicon cells to make them more efficient. We are just getting to the point in some of our work where some automation is desired, but we expect to build a fair number of various machines in the future and may even become a machine builder at some point (Our business model is flexible in this difficult funding environment!).

I am a skilled electrical engineer and have lots of embedded C and embedded linux programming experience. In the past, I've always used microcontroller boards (mostly ones I designed) along with relays and other external interface hardware. But I do feel there is something to be said for industrially hardened I/O and using hardware that can be purchased easily rather than stuff I build myself.

This first application I am looking at right now is very simple and probably could be done even with some of the ultra low end stuff all the PLC vendors offer or a bunch of programmable relays. But ideally I could select and start gaining experience with a PLC platform that could grow with our needs and would allow for code reuse from previous projects.

I am a little shocked to find that basically none of the major PLC vendors offer hardware that can be programmed in C. Yes, I know there are structured text, instruction list, and other options available. But I already know C well, and so would most other electrical engineers. I have read a bunch of threads here about the virtues of ladder logic, and I'm sure it makes sense in some cases, but for my needs C would be hugely better. I find it weird that the vendors don't provide for working with the hardware on this level; after all it is a lot more complicated to write the embedded and PC side software that allows graphical ladder programming to work. Just making a C compiler with some support libraries should be nearly trivial since compilers certainly exist already for the microprocessors that the vendors are using inside the PLCs.

I don't accept the argument that ladder is inherently better than C for high reliability, industrial, or other places where you don't want the blue screen of death to happen. Automotive computers, flight controls, and health care equipment don't run off ladder logic programmed PLCs. There are well understood tools and techniques for multi-threaded and high reliability programming in C. There is a huge market of PC104 embedded PCs for just such applications. But I like the compact, rail mount nature and low end offerings of the PLC world, which is why I am looking into it. It seems a bit silly to have a PC104 stack in a machine that you could build with a handful of timing relays.

Anyway, I was hoping someone would have some leads for reasonably priced hardware from a reputable and somewhat stable vendor that can be programmed in C. There are a number of vendors that sell what are essentially rail mount industrial PCs, but the minimum price points on these are pretty high.

If I can't find one line of PLCs that goes from simple and cheap up to complex and expensive that can all be programmed in C, there are two other options I'm considering:

- Buy remote I/O blocks from Wago, Beckhoff, Sixnet, Acromag, or others and run them from a microcontroller board or embedded PC over modbus or ethernet

- Have two PLC solutions: one for simple applications, which would use a cheap PLC programmed in ladder or whatever the vendor supports, and one for complex applications which I would address with a more pricey IPC style PLC.


I've been looking at the Koyo stuff (Click and DirectLogic), which looks great, affordable, and I can buy easily off the web. There are also reasonable low-medium end offerings from Omron, IDEC, Modicon, Mitsubishi. None can be programmed in C though!

Anyway, your thoughts are welcome,
thanks,
-Holly

[nic00]

Off topic here.. Was just reading an article on solar cells and about quantum dots, Making the solar cells much more efficient. Are u involved with this kinda thing?

[DEVO]

Take a look at B&R PLC's: www.br-automation.com

Their software, Automation Studio, allows you to use either ladder logic, C programming, Instruction List, Sequential Function Chart and Structured Text.

They have a lot of options for hardware and HMI's.

Don't count out using ladder logic for some of the machine control, it is straight forward, easy for others to follow and almost everyone in the automation industry is familiar with it.

Good Luck.

[Holly Gates]

 nic00, on Mar 13 2009, 03:24 PM, said:

Off topic here.. Was just reading an article on solar cells and about quantum dots, Making the solar cells much more efficient. Are u involved with this kinda thing?

Actually our company is based on the idea of not doing anything too fancy on the basic material side, on the theory that this will allow our technology to go to market sooner. We just work on plain ol' multicrystalline silicon as a substrate. Our innovations are in two areas: adding a light trapping texture to the surface of the cells to help them capture more of the light that hits them, and in improving the metallization for collecting current off the cell.

But funny enough my housemate is a grad student at MIT and is working on quantum dot based solar cells. He just gave a poster at an energy expo at MIT last week; I wonder if the article you saw involved his work

-Holly

 DEVO, on Mar 13 2009, 04:18 PM, said:

Take a look at B&R PLC's: www.br-automation.com

Their software, Automation Studio, allows you to use either ladder logic, C programming, Instruction List, Sequential Function Chart and Structured Text.

They have a lot of options for hardware and HMI's.

Don't count out using ladder logic for some of the machine control, it is straight forward, easy for others to follow and almost everyone in the automation industry is familiar with it.

Good Luck.

Ah, nice lead! These are PC based systems it seems; do you know what the pricing is like for a low end CPU? How about expansion modules?

I wouldn't be opposed to having ladder as an option, its just that I want C as an option too.

thanks,
-Holly

[nic00]

Quote

Off topic here.. Was just reading an article on solar cells and about quantum dots, Making the solar cells much more efficient. Are u involved with this kinda thing?


Actually our company is based on the idea of not doing anything too fancy on the basic material side, on the theory that this will allow our technology to go to market sooner. We just work on plain ol' multicrystalline silicon as a substrate. Our innovations are in two areas: adding a light trapping texture to the surface of the cells to help them capture more of the light that hits them, and in improving the metallization for collecting current off the cell.

But funny enough my housemate is a grad student at MIT and is working on quantum dot based solar cells. He just gave a poster at an energy expo at MIT last week; I wonder if the article you saw involved his work

-Holly

The actual article was in new scientist (7th March Edition) on pg 20 written by David Robson

This post has been edited by nic00: 13 March 2009 - 03:40 PM

[paulengr]

 Holly Gates, on Mar 13 2009, 03:10 PM, said:

Hello all, I was hoping you could offer some thoughts on selecting a PLC. I'm working at a solar cell startup where we are working on new processes for silicon cells to make them more efficient. We are just getting to the point in some of our work where some automation is desired, but we expect to build a fair number of various machines in the future and may even become a machine builder at some point (Our business model is flexible in this difficult funding environment!).

I am a skilled electrical engineer and have lots of embedded C and embedded linux programming experience. In the past, I've always used microcontroller boards (mostly ones I designed) along with relays and other external interface hardware. But I do feel there is something to be said for industrially hardened I/O and using hardware that can be purchased easily rather than stuff I build myself.

This first application I am looking at right now is very simple and probably could be done even with some of the ultra low end stuff all the PLC vendors offer or a bunch of programmable relays. But ideally I could select and start gaining experience with a PLC platform that could grow with our needs and would allow for code reuse from previous projects.

I am a little shocked to find that basically none of the major PLC vendors offer hardware that can be programmed in C. Yes, I know there are structured text, instruction list, and other options available. But I already know C well, and so would most other electrical engineers. I have read a bunch of threads here about the virtues of ladder logic, and I'm sure it makes sense in some cases, but for my needs C would be hugely better. I find it weird that the vendors don't provide for working with the hardware on this level; after all it is a lot more complicated to write the embedded and PC side software that allows graphical ladder programming to work. Just making a C compiler with some support libraries should be nearly trivial since compilers certainly exist already for the microprocessors that the vendors are using inside the PLCs.

I don't accept the argument that ladder is inherently better than C for high reliability, industrial, or other places where you don't want the blue screen of death to happen. Automotive computers, flight controls, and health care equipment don't run off ladder logic programmed PLCs. There are well understood tools and techniques for multi-threaded and high reliability programming in C. There is a huge market of PC104 embedded PCs for just such applications. But I like the compact, rail mount nature and low end offerings of the PLC world, which is why I am looking into it. It seems a bit silly to have a PC104 stack in a machine that you could build with a handful of timing relays.

Anyway, I was hoping someone would have some leads for reasonably priced hardware from a reputable and somewhat stable vendor that can be programmed in C. There are a number of vendors that sell what are essentially rail mount industrial PCs, but the minimum price points on these are pretty high.

If I can't find one line of PLCs that goes from simple and cheap up to complex and expensive that can all be programmed in C, there are two other options I'm considering:

- Buy remote I/O blocks from Wago, Beckhoff, Sixnet, Acromag, or others and run them from a microcontroller board or embedded PC over modbus or ethernet

- Have two PLC solutions: one for simple applications, which would use a cheap PLC programmed in ladder or whatever the vendor supports, and one for complex applications which I would address with a more pricey IPC style PLC.


I've been looking at the Koyo stuff (Click and DirectLogic), which looks great, affordable, and I can buy easily off the web. There are also reasonable low-medium end offerings from Omron, IDEC, Modicon, Mitsubishi. None can be programmed in C though!

Anyway, your thoughts are welcome,
thanks,
-Holly

www.softplc.com

I forgot whether you can do C modules but I know you can do Java ones. I believe you can do both.

For what you are trying to do, the most common approach is what you describe...do everything in a microcontroller that interfaces over onto industrial I/O. If you look at the way that softplc does it, it's a pretty good model. For instance they use ADAM I/O cards which are based on Modbus.

The reason that you see such a huge difference is that you have to realize what the markets are. Embedded systems are usually developed either as "one-off" projects for specialized applications, or else for "production" equipment which would be treated as a black-box by the end user. With automation systems, you have long running systems that have to be subject to routine maintenance and small as well as large upgrades on a more or less continuous basis. Everyone involved from electricians to engineers to programmers to often even production folks have to be able to understand them. With a C-based system, that is nearly impossible. With ladder-logic, it is more or less "self-documenting" because the basic language is based on an existing electrical language (relay logic).

It might look simple though, but don't make the mistake of assuming that it's a limited language. Especially with some of the more advanced versions (PAC systems), very complicated controls algorithms can be implemented without much effort at all. I wouldn't recommend doing an FFT or cross-correlation (although those can be done!), but control loops such as PID or SMC are easy to implement and often there are built-in instructions for these. State machines are also easily constructed. And despite that, troubleshooting can still be handled by pretty average folks.

[Mickey]

ControlMicrosystems's SCADAPack series of controllers support "C/C++, see link below.

http://controlmicros...pack-plcs-rtus/

[Crossbow]

Mitsubishi Electric offers a CPU for the Q Series which is programmed in C. Look for the Q06CCPU.

[DEVO]

Ah, nice lead! These are PC based systems it seems; do you know what the pricing is like for a low end CPU? How about expansion modules?

I wouldn't be opposed to having ladder as an option, its just that I want C as an option too.

thanks,
-Holly
[/quote]

I do not know the pricing, there are many choices so you would really need to talk to a local rep.

I just finished a project at the end of 2008 for a tapping machine that used a PP45. It is a color HMI with the processor built in. Then we had some X20 I/O which is expandable and was easy to get running. This also had two servos connected as well.

[TConnolly]

Having both programmed embedded controllers in C and PLCs, I suggest that at least for discrete IO programming you learn to use ladder. Despite the initial knee jerk reaction that causes people to think ladder is a low level language, its actually not. Whether a language is high level or low level is determined by the level of abstraction it provides from the hardware, not by the actual complexity of the language.

For example. consider reading and writing a single bit of memory, which is what the ladder language was designed to to do. While its not at all difficult to do in C, it still requires the construction of a bit mask and ANDing or ORing. But it ladder its a single simple instruction. There is nothing un-sophisticated about using it. While the C programmer is still defining bit masks the ladder programmer has finished the subroutine and moved on.

Next consider your customer. Most utility companies have people on staff who understand and use ladder, but not necessarily C. And to a customer the ability to maintain their equipment themselves is of paramount importance, without having to depend on a "black box" accessible only by a tech support guy at another company in another location. Your competitor using a ladder PLC has a leg up on you in that area.

Learning ladder isn't hard, especially for a C programmer (besides I've said it before, a C background makes one a better ladder programmer) Jump in and learn to appreciate ladder for what it is, and for what it isn't.

[Holly Gates]

 Alaric, on Mar 16 2009, 12:57 PM, said:

Having both programmed embedded controllers in C and PLCs, I suggest that at least for discrete IO programming you learn to use ladder. Despite the initial knee jerk reaction that causes people to think ladder is a low level language, its actually not. Whether a language is high level or low level is determined by the level of abstraction it provides from the hardware, not by the actual complexity of the language.

For example. consider reading and writing a single bit of memory, which is what the ladder language was designed to to do. While its not at all difficult to do in C, it still requires the construction of a bit mask and ANDing or ORing. But it ladder its a single simple instruction. There is nothing un-sophisticated about using it. While the C programmer is still defining bit masks the ladder programmer has finished the subroutine and moved on.

Next consider your customer. Most utility companies have people on staff who understand and use ladder, but not necessarily C. And to a customer the ability to maintain their equipment themselves is of paramount importance, without having to depend on a "black box" accessible only by a tech support guy at another company in another location. Your competitor using a ladder PLC has a leg up on you in that area.

Learning ladder isn't hard, especially for a C programmer (besides I've said it before, a C background makes one a better ladder programmer) Jump in and learn to appreciate ladder for what it is, and for what it isn't.

I'm sure it wouldn't be that hard to learn ladder, and I agree that it is much easier to tackle for people without programming experience. We have a bunch of mechanical engineers around here who probably would rather do stuff in ladder than in C. But I would guess that there are a lot more engineers out there in general who know C rather than ladder. So from my perspective I can get almost any electrical engineer or software engineer in here and they will be able to work on C code, rather than having to search out an engineer with specialized PLC programming skills.

I have no experience with ladder, but I have had a few unfortunate encounters with graphical based programming systems that got too complex. For example, labview is great for tasks of low to medium complexity. But when things get quite involved, it becomes totally unwieldy and nearly impossible to debug. Having to debug someone else's C code is annoying, but fundamentally more workable than a huge tangle of interlocking graphical elements in a big blob.

The comment about who the customer will be is astute. For internal use, the customer is me or another engineer likely to know C, not an electrician or tech.

My ideal solution would support both C and ladder (and maybe other stuff, but if it had those two I think it would serve the two potential user groups here: engineers who can program, and engineers who have not done so before).

There is something to the idea that ladder has more symmetry with how a PLC operates (regular scan, compute, output cycles). But there are reasonable ways to do parallel tasks in C too; the basic cycle of a PLC resembles the time slices of a multi-tasking OS like linux.

Another thing I like about C is the potential for portability. But if I went with something like CoDeSys, this could also be realized with ladder.

Thanks to people in the forum, I now have two very good candidate systems in B&R and Beckhoff.

thanks very much!
-Holly

[BobLfoot]

Read your posts and wanted to interject my humble opinion from 30 yeasrs of working in Industrial Automation. {Electrician to Project Engineer}. You need to carefully define and envision who is going to maintain and operate your equipment when it reaches the end customer. If it Engineers such as yourself holding degrees from MIT, RIT, CalSci and such then "C" is probably your best choice. If it is Union Electricians and maybe even Operators who will be tasked with servicing and operaitng your machine the I would seriously think about Ladder or perhaps structred text. Most Electricians don't have a B.S. in Programming, but they understand ladder really well. You are kidding yourself if you think everyone that buys and works on your machine will posess your skill level. Writing the code in what is best for you is best to develop, but not to have a marketable and servicable product. I worked on several jobs were the end customer hired the firm I was at to tear out PC based controls run from Linux and C platforms and repalce it with PLCs and ladder logic. Not because the Linux stuff didn't run and run well, but because their local people couldn't maintain it. Bottom Line - Think long and hard about your final end user whne choosing the controls hardware.

[TConnolly]

[paulengr]

 Holly Gates, on Mar 17 2009, 01:15 PM, said:

I have no experience with ladder, but I have had a few unfortunate encounters with graphical based programming systems that got too complex. For example, labview is great for tasks of low to medium complexity. But when things get quite involved, it becomes totally unwieldy and nearly impossible to debug. Having to debug someone else's C code is annoying, but fundamentally more workable than a huge tangle of interlocking graphical elements in a big blob.

-Holly

OK, now I understand where you are coming from. Labview is quite unlike pretty much any other programming language out there. I don't know quite how to put this but Labview requires a completely different and very funky thought pattern that is unlike any other programming language. It is similar to what it takes to deal with say SQL...it takes much longer to learn to "think in Labview" if you are used to anything else. If you can do it successfully, and write very modular code (lots of little subroutines that do just or or two things instead of great big ones), it isn't so hard to maintain. In a traditional language, when things get ugly, refactoring code is a simple matter of doing some cut/paste operations. In Labview, this is far more difficult to do because of the 2-D structure of your code. So when it gets to the point where it's time to modularize some sections that have gotten unwieldy, it's actually difficult to do so.

Don't worry. Ladder logic isn't like that at all. It is very intuitive. And cutting/pasting is just as simple. There is very little risk of turning it into spaghetti because you can easily insert and remove rungs, and do block copy/paste operations. Some processors even have C "structs" (called a user-defined data type on a Rockwell PLC), and most of them have all kinds of implementations of subroutines and other forms of code modules.

[DanW]

Check out Codesys.

Codesys is a development environment that allows for editors for programming in

Instruction List
Sequential Function Chart
Function Block Diagram
Structured Text
Ladder Diagram
Continuous Function Chart

statement from their home page:
CoDeSys is one of the most powerful IEC 61131-3 programming tools for controllers applicable under Windows. All five programming languages of the standard are supported. CoDeSys produces native machine code for all common processors. CoDeSys combines the power of advanced programming languages such as C or Pascal with the easy handling and operational functions of PLC programming systems.

http://www.3s-softwa...x.shtml?en_oem1

[JesperMP]

C is a general purpose langauge that can be used for just about anything. And that is a bad thing, because you can much more easily create a serious programming error, than you can with a typical PLC language.
All PLC programming languages are limited when compared to C, but for good reason.
Structured Text was created to get most of the programming power of C or Pascal, but without most of the dangers.

Holly Gates said:

Automotive computers, flight controls, and health care equipment don't run off ladder logic programmed PLCs.

The software and hardware verification and approval for these is gruelling.
It is a completely different ballgame. Your solar cell startup system probably does not fall in any of the mentioned categories.

Holly Gates said:

There is a huge market of PC104 embedded PCs for just such applications

For the lower cost variants used for general purpose applications (i.e. non-critical) the reliability is so-so. An example I can think of is the electronic ticketing 'kiosks' in airports. If there are 10 of these, 2-3 of them are always out of order.
A new development is starting where manufacturers from the 'hard' industrial automation world are beginning to supply 'embedded PCs' that are at least as reliable as regular PLCs, and quite affordable too. Examples that I know of are Beckhoff and Siemens.

Even if there are a few PLCs that support the C language, if I were you I would consider to switch to ST.

[RussB]

You can program the GE Fanuc PAC with "C" if you want.
www.gefanuc.com - for commercial information
www.gefanuc.com/support - for technical information

I recommend the RX3i for excellent cost:performance ratio.

[ndzied1]

Maybe this would be more up your alley:

http://cubloc.com/

Their products program in BASIC and Ladder. They seem to come as individual chips or on boards or in HMI Touchpanels.

I have never used them but see their adds all the time in Nuts & Volts Magazine.

[PLCMentor.com]

Holly,
I think you can sum up a lot of the answers you have seen here with what I stress with my engineers - Program for your audience. As stated by Bob, if you are programming for engineers or scientists in a research capacity then C might do well for you. Though Jesper makes some valid points about the benefits of the industrial languages in his post that should make you pause. If these systems are going in an industrial environment and your PLC will be anything other than a 'black box' then I think you seriously need to consider ladder, structured text, or function block implementations of your system. That is what your audience will be familiar with. If it will be a 'black box' implementation (ie, your code will be proprietary and the end user will NEVER be allowed to access or troubleshoot by looking at it), then C might be fine assuming that you go through the appropriate testing.

Let me throw another wrench in the works by disagreeing with your premise that the majority of electrical engineers will be more familiar and comfortable with C than with ladder. I dont see it. Ladder is designed around how electrical engineers are trained to think. I deal with electrical engineers on the industrial level. Many would not know what to do with C when they are a few years out of college. Some of the older guys may not even know how to spell C - they learned FORTRAN (and forgot it years ago). I think you are looking at the engineers in your environment (I am assuming design and research) and trying to cast all engineers in that light.

Let me add another wrench in the works. Before you select your equipment based on whether or not it will program in C, check with your prospective clients. Do they have standards that will nullify your design? What will it do if you design your system around xyz system and the majority of your clients say, "No, we use Allen Bradley (or Siemens, etc)?" Your may always have a chance of that happening, but if it is a possibility then your standard should be based around what will be requested the most. Keep in mind that in the US AB owns 65-70% of the market. Internationally Siemens is king. Where will your systems go? This may be a moot point in your case, but with many of the OEMs we work with, this can be a very costly decision.

To sum it up again - figure out your audience - select and program to that audience.

Russell