Searching \ for '[PIC] Comparing a PIC with a PLC' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Comparing a PIC with a PLC'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Comparing a PIC with a PLC'
2008\11\29@032157 by Jinx

face picon face
I'm assessing a job, which I think a low-end 18F can do fairly simply. The
logic is quite straight-forward. Inputs are two 4-20mA transducers, a mains
relay, and two temperature sensors, with a real-time clock. Outputs are
a couple of alarm lines, LCD, and a few pushbuttons to set parameters

The scenario might be something like - If transducer1 is a certain value
and temperature sensor2 is a certain value, then turn on the mains and
measure temperature sensor1 after 1 minute to make sure the appliance
(a chiller) is running. And various IF....THEN combos like that

I was talking over the pricing structure with a couple of people and they
both suggested that I base it at less than the cost of an 'industrial PLC'
which would be needed. Their thought is that the lower (but not too low)
price mentioned in the same breath as a PLC will make my PIC sound
more attractive. Can't say I'm 100% about that but they won't shut up
about PLCs !

I'm a complete ignoramus in the PLC department

http://en.wikipedia.org/wiki/Programmable_logic_controller

To me, after reading that, it seems a PLC is way OTT for this job, and
especially if you know how to program a micro yourself. This assessment
may be for 300 units (optimistic "Everyone will want one" salesman !!)

I guess the material costs, not including sensors, using a PIC may be around
NZ$70 (US$35-$40), and software perhaps a little less (@ Q = 300), then
there's markup on that

Can anyone with practical experience of PLCs give me any advice as to
whether the cost of a PLC system is even worth considering ? And, if so,
how do prices compare ?

TIA

2008\11\29@073050 by Walter Banks

picon face
Quick comment. PLC hardware cost will be higher, software costs lower
reliability higher.

w..

Jinx wrote:

{Quote hidden}

> -

2008\11\29@074133 by Vasile Surducan

face picon face
I'm affraid you can't compare a PIC with a PLC. A PLC can be made from
a PIC, analogic/digitall  stuff, communications, etc highly modulised
and a graphical IDE for easy programming. I don't think you'll find a
PLC bellow $40, but also I think your price for the PIC system is also
unprized (maybe you was too optimistic, it's about industrial
application not an academic demonstration, meaning standardisation,
temperature variation an noise environement problems, low qualified
operation personell, etc).
A good PLC is designed in a long time and many design respin, do not
subappreciate such effort, it's no difference for creating a good PIC
project.

Vasile

On 11/29/08, Jinx <spam_OUTjoecolquittTakeThisOuTspamclear.net.nz> wrote:
{Quote hidden}

> -

2008\11\29@082844 by Carl Denk

flavicon
face
Check out TRI-PLC.COM
They have some low end PLC's that are inexpensive. Programing is with a
ladder diagram that allows embedded Basic routines. You can download a
trial version of the software. They have a tech support forum, in
addition to telephone that is very good. On the forum check out the time
it takes for tech support to respond.

As was said, PLC's can be expensive, but one could take a PIC and make a
PLC, but that would be a lot of effort, where a PLC might be able to do
it reliably and quick program/setup. Since I got into thePLC's 4 years
ago, there have been advancements, in particular in the low end units.

Jinx wrote:
{Quote hidden}

2008\11\29@085903 by Xiaofan Chen

face picon face
On Sat, Nov 29, 2008 at 4:20 PM, Jinx <.....joecolquittKILLspamspam@spam@clear.net.nz> wrote:
> I guess the material costs, not including sensors, using a PIC may be around
> NZ$70 (US$35-$40), and software perhaps a little less (@ Q = 300), then
> there's markup on that
>
> Can anyone with practical experience of PLCs give me any advice as to
> whether the cost of a PLC system is even worth considering ? And, if so,
> how do prices compare ?

There are a few Sub US$100 PLCs. But not US$40. And most
of the US$100 PLC will not have analog input points.

Eg:
http://www.ab.com   Allen-Bradley Microclogix ML1000
1761-L10BXB 10 digital points only, about US$99, free software
No expansion available for ML1000.

Pico controller is another option.
http://www.ab.com/programmablecontrol/plc/pico/controller.html

Automation Direct  D0-05DD +
D0-05DD 10 digital points only, US$99, 4ch analog
expansion I/O will cost another US$79

The good thing about PLC is the shorter development
time and the good system reliability.


Xiaofan

2008\11\29@090734 by microsoftwarecontrol

flavicon
face
I can do PIC well, I never both PLC.

PLC=PIC+something

You need = PLC + prmg = PIC + something + prmg




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2008\11\29@104037 by Forrest W. Christian

flavicon
face
All a PLC really is is a small CPU configured in typically a ruggedized
configuration, with additional Ruggedized I/O, and typically programmed
using Ladder Logic.

In recent years, the cost of a PLC have dropped rapidly.   The first PLC
I worked with is now being sold as the DirectLogic 305 series by
Automation Direct (at the time it was GE Fanuc Series 1, but TI was
starting to make modules for it).    Back in the 80's when I was doing
this work, the costs were significantly higher.   Now, they're really
inexpensive.

Take your application for example....   for a couple hundred USD
(perhaps 300 w/ the user interface), you can have a complete "real" PLC
capable of everything you describe.   The real strength of a PLC is that
you can buy this off of the shelf hardware, hook up your control lines
to it, and spend a couple hours programming it, and you're ready to go.  
And the "ruggedizing" needed in an industrial environment is pretty much
already done.    It's also flexible (oh, you don't want it to run with
the door open, well, just add a switch and a couple more lines of ladder
logic, and off you go).      For industrial machinery where the actual
programming in use is often unique to that specific machine, it's
great.   If someone came to me with an application for an industrial
machine or similar (like  your application), that only had a dozen or so
total production runs, or if the requirements weren't stable from
machine to machine, I would spec a PLC, and not even really consider a
custom PIC solution.

Now, back to your application.    Because your application needs are
fixed, yes, you should be able to build for a lower component cost.  
The cost of a 18F, and some I/O conditioning, plus the interface, is
going to be significantly lower than the cost of a PLC.   The question
being is how many units are going to be needed, and how "fixed" is the
needs for each machine.   As long as the quantity is high enough, and
the needs from unit to unit aren't going to require a whole new PIC
application, then I'd say go for it.  

-forrest

Jinx wrote:
{Quote hidden}

2008\11\29@113321 by Xiaofan Chen

face picon face
On Sat, Nov 29, 2008 at 11:40 PM, Forrest W. Christian
<forrestcspamKILLspamimach.com> wrote:
> All a PLC really is is a small CPU configured in typically a ruggedized
> configuration, with additional Ruggedized I/O, and typically programmed
> using Ladder Logic.

This may be true last time. Nowadays bigger PLCs are using very
powerful CPUs and can do a lot of things. Some companies (Beckhoff,
B&R or similar) use PC grade components. And now you can use different
programming languages for it. But Ladder Logic is still the most popular
option.

Of course there are smaller PLCs (pico or nano PLCs). Some low
end PLCs can use 8-bit MCUs like 8051s.But the newer
generation nano/pico PLCs are using quite powerful 16/32bit
MCUs.


Xiaofan

2008\11\29@120801 by Bob Axtell

face picon face
We use both PLCs and PICs. The problem is that some utility customers
prefer PLCs because they know what to expect, and they greatly respect
the PLC. We "hide" the PIC and allow the PLC to perform highly visible
chores.

Ladder Logic appears to be simple but in fact is very difficult to
program, even very simple tasks
take many hours. I was never able to get PLCs to do anything, but
other people can perform magic. Go figure.

--Bob A

On Sat, Nov 29, 2008 at 8:05 AM, Xiaofan Chen <.....xiaofancKILLspamspam.....gmail.com> wrote:
{Quote hidden}

> -

2008\11\29@125329 by Brent Brown

picon face
Hi Jinx,

Have a look at the class of really small baby PLC's sometimes called smart relays. I
think they are somewhere around NZD200 each. Companies like Idec and Siemens
and others. Need to consider them as an option for small projects (think of the
development costs), they definetely can compete with build-your-own micro based
design in some places. Customers like them because: off the shelf item, industrial
proven design, packaging, compliance, can use an electrician to install and program
it.

> Can anyone with practical experience of PLCs give me any advice as to
> whether the cost of a PLC system is even worth considering ? And, if so,
> how do prices compare ?

--
Brent Brown, Electronic Design Solutions
16 English Street, St Andrews,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: +64 27 433 4069
eMail:  brent.brownspamspam_OUTclear.net.nz


2008\11\29@160055 by Jeff Morton

picon face
In addition to their ruggedness, another key in the Programmable Logic
Controllers is that they are designed to be user-programmable with a
high-level language.  The device's firmware (handles booting, communication,
and other low-level functionality) executes much higher-level application
programming.  This high level programming can be compiled or interpreted and
can be developed using ladder logic, function block diagrams, or a simple
text based language.

This high level logic can usually be updated across the network.  In this
way, application changes (for example, adding a chilled water flow sensor
requirement to your chiller example) would not require a firmware update,
but rather a very simple upload to the device.

Your application may or may not require this degree of
user-maintainability.  If not, a straightforward PIC solution would make a
lot of sense.  Otherwise a Programmable [high level] Logic Controller
solution may be the way to go (and as others have said, this could be
implemented with a PIC).

Regards,
Jeff


All a PLC really is is a small CPU configured in typically a ruggedized
{Quote hidden}

2008\11\29@162245 by Carl Denk

flavicon
face
On.line monitoring and control, either via. local RS-232 or via. web is
very nice. You can modify the program, download, reset the newly loaded
software, and see the results real time, status of all registers,
counters, timers, inputs, outputs, and memory. All within a minute or 2.
The TRI-PLC software has an on line help that includes a list of all
BASIC commands with examples of usage that can be copy/paste to your
software. With timers, the unit is a nice easy to use quantity like 0.1
second for the low speed. As was said, most of the grunt work is done,
jump right in to your application. The Tri-PLC I have, the input output
buffer chips are all socketed. If you happen to fry one, no big thing, a
readily available inexpensive chip. Powering stepper motors or measuring
frequency is also readily available. I measure the 60 hz of a generator
with one of the inputs.

2008\11\29@163809 by Rich

picon face
Is that because the PIC reliability is inherently lower or because the
overall engineering and design of the PIC system is less reliable?
{Original Message removed}

2008\11\29@163924 by Jinx

face picon face
Everyone, thanks for replies and product links

PLC prices are lower than I expected. The addition of function (eg
analogue and comms) modules pushes the price up though. And those
functions are already available on a PIC without too much fuss

The potential 300 installations in this application are very similar, with
minor individual differences that can be accounted for

The original question was how prices compare between PICs and
PLCs, so that I can work out a pricing schedule for my intended PIC-
based unit

Cost is somewhat of an issue. To some extent I can bear s/w time -
there's the learning curve of Ladder Logic vs my library routines for
PICs - but not change hardware costs, which will be higher for PLCs

So, for this project, based on your helpful inputs, I'll use PICs but
with at least a little understanding of PLCs. The bottom line is that
I'd want to give the customer the flexibility and ruggedness of a PLC
at a PIC price

That said, I can see a couple of applications for PLCs where I'd
considered only PICs

2008\11\29@165307 by Jinx

face picon face
> We use both PLCs and PICs. The problem is that some utility
> customers prefer PLCs because they know what to expect, and
> they greatly respect the PLC. We "hide" the PIC and allow the
> PLC to perform highly visible chores

Bob, I find that interesting. I don't have "PLC customers" as such
but appreciate why yours would go with what they know. You can
guess that's why I'd lean towards PICs - it's what I know

So what it comes down to is ease-of-use and maintainability in the
end product, as pointed out most recently by Jeff and Carl

2008\11\29@165452 by Jinx

face picon face
> Is that because the PIC reliability is inherently lower or because the
> overall engineering and design of the PIC system is less reliable?

The impression I'm getting is that the brains, whatever it is, of a PLC
are protected with buffer circuitry. You could do the same with any
micro-based board

2008\11\29@173804 by Carl Denk

flavicon
face
The one model and manufacturer's PLC's I have are that way, probably
many other units are that way, but I would assume that some might be
sealed units, soldered chips or surface mount devices. A good point,
that should be part of your specifications when selecting a PLC. On mine
the buffer addressing is multiplexed. Note that in general the ladder
with embedded programming is executed, and then at the end of the
ladder, the buffers are strobed and all inputs/outputs are set at that
time. One of the gotcha's is setting an output early in the ladder, and
then farther down the ladder, changing the setting. The last setting
generally prevails.

The reliability of any unit depends on design, programming,  
fabrication, and application. The PLC somewhat eliminates the design and
fabrication from the variables. Certainly a PIC could do the job, but
think about my PLC has 40 inputs and 40 outputs, including 8 ADC
implementing that with a PIC including the subject of this message -
buffering where a fried chip can be changed out quickly. The ladder
diagram programming may seem difficult at first, but once one catches on
a bit, it becomes very straight forward, easy to debug or modify. The
ladder programming allows doing an step either on always, on rising or
falling edge of a input. The embedded high level programming like BASIC
allows working with numbers to scale ADC in addition to sending text and
data out to a network. I encourage using the TRI-PLC free trial
jhttp://www.tri-plc.com/TLeval/runTRiLOGI.htm

Also on their web site there are numerous example of applications

Jinx wrote:
>> Is that because the PIC reliability is inherently lower or because the
>> overall engineering and design of the PIC system is less reliable?
>>    
>
> The impression I'm getting is that the brains, whatever it is, of a PLC
> are protected with buffer circuitry. You could do the same with any
> micro-based board
>
>  

2008\11\29@174133 by Royh

flavicon
face
Jinx wrote:
{Quote hidden}

Hi Jinx,

Zelio - Schneider have a range of so called smart relays
http://www.schneider-electric.com/corporate/en/products-services/automation-control/products-offer/range-presentation.page?p_function_id=18&p_family_id=233&p_range_id=531

They provide a free down load of there ladder logic.
http://www.schneider-electric.com/corporate/en/products-services/automation-control/products-offer/range-presentation.page?p_function_id=18&p_family_id=233&p_range_id=531#

Regards Roy

2008\11\29@182000 by Victor Faria

picon face

----- Original Message -----
From: "Royh" <@spam@royhKILLspamspamxnet.co.nz>
To: "Microcontroller discussion list - Public." <KILLspampiclistKILLspamspammit.edu>
Sent: Saturday, November 29, 2008 5:41 PM
Subject: Re: [PIC] Comparing a PIC with a PLC


{Quote hidden}

Jinx ,
If you don't like Ladder take a look here.
they do have a very easy language , and the price is right.
http://www.splatco.com/


Victor

2008\11\29@185208 by Jinx

face picon face
Roy, Victor, thanks. I'm looking into everything

One other factor that will be an influence is that recently the NZ$ has
taken a dive against the US$. Currently US$1 ~ NZ$1.82, so any
product I find in US$ will probably be 2x that in NZ$, landed

2008\11\29@185818 by Rich

picon face
It all depends on the application.  If you just want to implement a ladder
diagram in real time control you could do that with a PIC with the right
SSR's or required drivers for your application, you can configure a PIC
based system to emulate the ladder.  But the PLC already has the software
for ladder logic, A/D converters, D/A converters, SSR's, bang-bang, PID and
other common control algorithms.  PLC's can be very simple or fairly
sophisticated.  Larger manufacturing systems have been moving toward
intranet based architecture for more demanding process control applications.
PLC's are being integrated into broader based computer architectures having
autonomous cells and communicating with remote wireless transducers
(transmitters)  in some cases.  PIC has more opportunity, in my assessment,
as the basis for a remote transmitter, preferably wireless; absolute
pressure or differential pressure, temperature, and so on.  Some mention on
this list about 4-20 mA piqued my interest because wired systems are being
phased out and replaced by reliable wireless systems.  Some systems are
already using satellite data communications.  I can see a time when HART
protocol will become obsolete.


{Original Message removed}

2008\11\29@193444 by Victor Faria

picon face
Splatco I believe is in Australia, if that will help.
They also have an office in Massachusetts, US

Victor

{Original Message removed}

2008\11\29@201005 by Jinx

face picon face
> Splatco I believe is in Australia, if that will help.
> They also have an office in Massachusetts, US

Thanks

2008\11\29@201554 by Jinx

face picon face
> this list about 4-20 mA piqued my interest because wired systems
> are being phased out and replaced by reliable wireless systems

I do use a combination in one application. An existing 4-20mA pressure
transducer is read by a 12F675 and transmitted using slow Manchester
to the main processor 50m away. Ideally the costly, 4-20mA transducer
would be replaced with a simpler device but, meh, it's already there

Comments have certainly made me take a look at current industrial
technologies and where I'm falling behind, thanks

2008\11\29@210048 by Xiaofan Chen

face picon face
On Sun, Nov 30, 2008 at 7:57 AM, Rich <RemoveMErgrazia1TakeThisOuTspamrochester.rr.com> wrote:
>.  Some mention on
> this list about 4-20 mA piqued my interest because wired systems are being
> phased out and replaced by reliable wireless systems.  Some systems are
> already using satellite data communications.  I can see a time when HART
> protocol will become obsolete.
>

That is your wish. HART will be there for a long long time. Wireless will
take years (or 10 years or 20 years) to replace wired systems. Even then
Wireless HART is the leading candidate in wireless world in process
automation.

Xiaofan

2008\11\30@031909 by Rich

picon face
Perhaps.
----- Original Message -----
From: "Xiaofan Chen" <spamBeGonexiaofancspamBeGonespamgmail.com>
To: "Microcontroller discussion list - Public." <TakeThisOuTpiclistEraseMEspamspam_OUTmit.edu>
Sent: Saturday, November 29, 2008 9:00 PM
Subject: Re: [PIC] Comparing a PIC with a PLC


{Quote hidden}

> --

2008\11\30@043427 by Vasile Surducan

face picon face
My opinion is that wireless will never replace entirely the wired
industrial applications.
Even the OFDM seems to be the right solution for noisy environements,
don't forget in industry is room for any kind of personell not only
(smart) engineers. A wireless transducer communication problem is much
difficult to be solved. The technician must have expensive tools for
solving minor communication problems which behaviour have nonsense for
a person without a small experience in RF (propagation, atenuation
measurements, modulations etc).

Imagine just a place where a welding machine is running continuously.
Tesla lovers knows what that means as RF spectrum. Any Zigbee will be
unuseable there. Even OFDM will probably cough.

Vasile

On 11/30/08, Rich <rgrazia1EraseMEspam.....rochester.rr.com> wrote:
> Perhaps.
> {Original Message removed}

2008\11\30@050947 by Peter

picon face
> Imagine just a place where a welding machine is running continuously.
> Tesla lovers knows what that means as RF spectrum. Any Zigbee will be
> unuseable there. Even OFDM will probably cough.

According to a recent article 802.11 networks jam zigbee already

Peter

2008\11\30@051627 by Peter

picon face
Bob Axtell <bob.axtell <at> gmail.com> writes:
> Ladder Logic appears to be simple but in fact is very difficult to
> program, even very simple tasks
> take many hours. I was never able to get PLCs to do anything, but
> other people can perform magic. Go figure.

PLC programming is a form of boolean logic programming. With the right tools (or
brains) and a symbolic logic optimizer/mapper once can turn normal algebraic
equations into ladder logic language. The people who do "magic" with PLCs do
just this (higher level design followed by translation/implementation in ladder
logic).

Peter


2008\11\30@062119 by Xiaofan Chen

face picon face
On Sun, Nov 30, 2008 at 6:09 PM, Peter <EraseMEplpeter2006spamyahoo.com> wrote:
>> Imagine just a place where a welding machine is running continuously.
>> Tesla lovers knows what that means as RF spectrum. Any Zigbee will be
>> unuseable there. Even OFDM will probably cough.
>
> According to a recent article 802.11 networks jam zigbee already
>

That is why Zigbee has basically failed in the industrial automation
market. It only has limited success in building automation.

Wireless Hart's success is also uncertain. I guess it will be more
successful than Zigbee as there are many backers.

There are also things like Industrial WiFi which has limited success
in monitoring applications (SCADA, RTU, etc). 2G/3G wireless are
also used. Normally the underlined data protocol is still proprietary.

Xiaofan

2008\11\30@071422 by Tony Smith

flavicon
face
> My opinion is that wireless will never replace entirely the wired
> industrial applications.
> Even the OFDM seems to be the right solution for noisy environements,
> don't forget in industry is room for any kind of personell not only
> (smart) engineers. A wireless transducer communication problem is much
> difficult to be solved. The technician must have expensive tools for
> solving minor communication problems which behaviour have nonsense for
> a person without a small experience in RF (propagation, atenuation
> measurements, modulations etc).
>
> Imagine just a place where a welding machine is running continuously.
> Tesla lovers knows what that means as RF spectrum. Any Zigbee will be
> unuseable there. Even OFDM will probably cough.


Try running comms thru an aluminium smelter sometime.  Wire didn't fare too
well, fibre optic did.

Tony

2008\11\30@093357 by Dennis

picon face
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

2008\11\30@150725 by Rich

picon face
Your argument makes sense.  Perhaps wireless is not yet as reliable in some
environments as needed in order to replace wiring.  But I have replaced a
lot of wiring with wireless in manufacturing plants and tank farms.  I have
integrated Allen Bradley PLC units into a networked architecture where the
PLC is on the network and can send and receive data that can be operated on
in approved locations. Real time operations, like pumping, mixing, pressure
regulating and so on are carried out by the local PLC.  Production rates,
failures and other product information is sent over the network and also to
a PLC that controls production floor score boards that everyone can see, and
also to the office of various managers and exec's.  The network is an
intranet rather than an internet. PLC's are pretty reliable in most noisy
environments but they are not as powerful as computers.  For places like
Class 1, Division 1, Group C explosive environments, intrinsic safety is
still the general rule but in some cases optical logic and fiber optic is
used, and also wireless.  However, regulations still require normal hard
wired fail safe. But perhaps wireless is not widespread as I may have
imagined based on limited number of installations.


{Original Message removed}


'[PIC] Comparing a PIC with a PLC'
2008\12\01@140422 by alan smith
picon face
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 <RemoveMEdenbarbEraseMEspamEraseMEverizon.net> wrote:

{Quote hidden}

> --

2008\12\02@115152 by Eoin Ross

flavicon
face
Sounds like a 'smart relay' would do the trick...

bb-elec.com/product_multi_family.asp?MultiFamilyId=39&Trail=32&TrailType=Top
"free" software - you'll need to get a programming cable with a special connector.

>>> Jinx <EraseMEjoecolquittspamspamspamBeGoneclear.net.nz> 29 Nov 08 03:20:43 >>>
I'm assessing a job, which I think a low-end 18F can do fairly simply. The
logic is quite straight-forward. Inputs are two 4-20mA transducers, a mains
relay, and two temperature sensors, with a real-time clock. Outputs are
a couple of alarm lines, LCD, and a few pushbuttons to set parameters

The scenario might be something like - If transducer1 is a certain value
and temperature sensor2 is a certain value, then turn on the mains and
measure temperature sensor1 after 1 minute to make sure the appliance
(a chiller) is running. And various IF....THEN combos like that

I was talking over the pricing structure with a couple of people and they
both suggested that I base it at less than the cost of an 'industrial PLC'
which would be needed. Their thought is that the lower (but not too low)
price mentioned in the same breath as a PLC will make my PIC sound
more attractive. Can't say I'm 100% about that but they won't shut up
about PLCs !

I'm a complete ignoramus in the PLC department

http://en.wikipedia.org/wiki/Programmable_logic_controller

To me, after reading that, it seems a PLC is way OTT for this job, and
especially if you know how to program a micro yourself. This assessment
may be for 300 units (optimistic "Everyone will want one" salesman !!)

I guess the material costs, not including sensors, using a PIC may be around
NZ$70 (US$35-$40), and software perhaps a little less (@ Q = 300), then
there's markup on that

Can anyone with practical experience of PLCs give me any advice as to
whether the cost of a PLC system is even worth considering ? And, if so,
how do prices compare ?

TIA


2008\12\03@115855 by Rich Satterlee

flavicon
face
Hi-

Sorry for entering the thread so late in the game.

There have been many good replies to the OP, I might suggest an alternative.

I have "whomped up" a PLC --> PIC translator toolchain.

It is in beta, but it is available via:

http://getok.net

The toolchain starts witha sourceforge.net (free) ladder logic compiler.
The project pages are gone, but the download is still there, or I could
supply a copy.

There is need of perl, which I use ActivePerl (free) or the linux perl
to do the job.

You run your ladder logic design through the ladder logic compiler, then
using a perl script I've developed you get pretty readable PIC assembly
language code.  Run that through the microchip assembler and you are
ready to rock and roll.

There are some software architechtural differences between the PLC and
"standard" code that are usually not apparent to the casual observer. Most
noteably, the internal cycle of most PLCs.  They have an input phase,
a rules phase and an output phase in that order, done in pretty much
an endless loop.  This is done to help prevent race conditions of
variables.  

Depending upon the application, ladder logic can be very effective and
a very fast way to program an application.  It was designed for
electricians who were replacing relay racks of process equipment. These
racks kind of looked like ladders, hence the name.

For combinatorial work such as Jinx has defined, it would tend to easily
transfer to ladder logic.  Read some stuff, do some minimal calculations,
and dump out some new state.

One caveat.  Not all ladder logic "coding" is the same.  Most vendors
have their own "take" as to symbols for things like counters, timers,
conditionals, etc.  Also math functions and non boolean conditionals
might be different.  However, they are pretty easy to map between
vendors.

Another "gottcha" is the relative lack of documentation capabilities
for ladder logic.  You can't easily take the "gui" input from your
design and transfer it to another ladder logic compiler.  Drat! You
will have to "hand code" the program back in again in the vendor's
visual editor (ladder logic designer).

Finally, on my website's documentation page (external) there is a link
to a VERY GOOD tutorial on ladder logic programming:

http://claymore.engineer.gvsu.edu/~jackh/books/plcs/

For those interested in learning more about PLCs.

Back to my little project, the code is extesible and can be used
with various capabilites spanning the 10F, 12F, and 16F lines of PICs.
Configureation can be done to assign inputs and outputs different than
what is originally programmed by me.  Mine has A/D, RS232, integer
math (mulitply/divide) timers and counters.  Variable number of
variables depending upon the size of the PIC choosen.

Finally, the little educational kits are no longer available.

Hope this missive helps.
 
Cheers,

  Rich S.






{Quote hidden}

> --

2008\12\03@121807 by William Couture

face picon face
On Wed, Dec 3, 2008 at 11:57 AM, Rich Satterlee <picSTOPspamspamspam_OUTsatterlees.com> wrote:
> Hi-
>
> Sorry for entering the thread so late in the game.
>
> There have been many good replies to the OP, I might suggest an alternative.
>
> I have "whomped up" a PLC --> PIC translator toolchain.
>
> It is in beta, but it is available via:
>
> http://getok.net

Interesting.  BTW:  Your "bitty.jpg" picture of the completed PIC10F200 PLC is
missing.

I also did some PLC stuff, but on Atmel chips, for work.

Of course, once I got it running, work was no longer interested in it... (sigh)

My boss is actually a fairly nice guy, and let me make it open source.

If anyone is interested, the files are at
  http://www.desmet-c.com/sources.shtml

I also have a later and better PLC editor/compiler, if you are intersted let
me know and I'll pretty it up for release.

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2008\12\03@150549 by Byron Jeff

flavicon
face
On Wed, Dec 03, 2008 at 11:57:37AM -0500, Rich Satterlee wrote:
> Hi-
>
> Sorry for entering the thread so late in the game.

Glad you showed up.

{Quote hidden}

Took a poke around. Looks interesting for someone who wants to do some
process control without having to get bogged down with programming the nuts
and bolts.

One problem I ran into. I downloaded the ladder logic application but it
won't run on my Linux box. First it complained about wx_gtk library being
missing. I installed one version (2.4.1) but the library didn't show up with the
proper softlink. So I hand linked it in and got the following error:

LadderDesigner: symbol lookup error: LadderDesigner: undefined symbol: __ti10wxListCtrl

I guess the 5 year old binary is incompatible with the current library.

When I get a chance I guess I'll compile the source and test it out.

There's a Christmas light controller calling my name this year. May be a
good test project for your system.

Thanks for the info.

BAJ

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...