My .02 worth as well. I designed a PIC based controller, complete with LED display (was moving toward an LCD) for a specific machine base control, with variations but pretty much consisted of 5 relays, and 4 AC inputs using HCPL2700 for the interface. The demand on the board was pretty small, say less than 100 per year and at the time, the small PLC to use were generally the AB SLC500 and the TCAT (for all you that remember those). Rockwell now does the AB stuff of course, and the smallest PLC you can get into is still going to run up close to $1K with the user interface and such. Back then, EZAutomation and AutomationDirect were not around so it was cost effective to spend $300 on a custom low volume control package. Now with the new Koyo and EZ220, you get alpha numeric displays and a PLC for the same cost, and its packaged to be in the NEMA enviroment. At that point, I dropped the redesign of the product and used the COTs products. I would love to redesign the product, but the demand is even lower now. The design originated with an project that used about 100 of these units, but that was more of a blip on the radar. So the bottom line is, if you have low production....PLC is often the least expensive way to go. --- On Sun, 11/30/08, Dennis wrote: > From: Dennis > Subject: Re: [PIC] Comparing a PIC with a PLC > To: "Microcontroller discussion list - Public." > Date: Sunday, November 30, 2008, 6:37 AM > I've read a lot of Bob Axtell's posts in the past > and Bob, you're NOT > dumb!! You CAN do "magic" with PLCs, it just > takes a slightly different > mindset. The following comments are intended for those PIC > listers that > may not be familiar with ladder logic. > > I've programmed quite a few PLCs and PICs (primarily > assembler), and I > feel quite comfortable with both. I sort of like ladder > logic - it can > frequently be easier to spot bugs with than PIC assembler. > It HAS been > some number of years since I've programmed a PLC, so > some of this may be > obsolete, but here goes: > > There are several points to keep in mind about ladder logic > because > different manufacturers do ladders differently. What > I'm about to cover > is an oversimplification, but it should get the point > across. > > As an example, all ladder logic "looks" like a > ladder, with a series of > "rungs". Each rung has "n" number of > inputs going left to right, > usually ending in one output at the extreme right side of > the rung. > Now, here's where the rub is: ladder logic has to be > interpreted in > order to determine what to do. Some manufacturers use a > page style, > where a certain number of rungs equal a page and the > interpretation runs > all rungs on the page top to bottom, left to right, meaning > all inputs > at the extreme left of a page are analyzed first, then move > over a > little and analyze all the next column of inputs, etc. > until you reach > the extreme left, at which point all outputs are set > according to the > results accumulated so far on this "page". The > next page is then > evaluated the same way. The biggest problem I've had > with this > technique is that the output of one rung is not immediately > available to > the next rung until the next pass through all the logic. > Can be hateful. > > Other manufacturers evaluate their ladder logic one rung at > a time, > going left to right, top to bottom. To me, this makes a > lot more sense > - and is easier to program correctly. > > As far as when data is available, if I remember correctly, > both styles > I've programmed capture the state of all external > inputs before each > complete pass through the ladder - and they are static > until the next > pass. However, the state of each "output" IS > available to succeeding > rungs on the same pass. The difference is that on the page > style, the > state of the output is only available on succeeding pages > and not on the > same page, where using the "one rung at a time" > method, the state of the > output is immediately available on the next rung. > > Bear in mind - I've only programmed a handful of > different brands many > years ago and I'm oversimplifying things a bit - just > trying to provide > you with the concepts. I got really burned with the > differences I've > described here because I didn't know there were > different ways to > evaluate the ladders and I was in a rush to get a new PLC > up & working > and didn't spend the time I should have reading the > manual (shame on > me!!). Only happened once!!! > > FWIW, I've found that drawing out a State Diagram, > followed by a > Karnaugh Map makes programming ladder logic MUCH easier to > develop and > debug. > > As much as I like PICs, if I HAD to get something up > quickly in a > production environment, I'd look HARD at a PLC - > it'd be a > no-brainer!!! Of course, if we're looking at many > hundreds of units and > cost was a serious issue, then maybe a different approach > would be > warranted. > > Just my 2 cents worth! > Dennis > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist