|
Hi all, I'm fairly new to PIC microcontrollers and have been experimenting for the last month or so with a PIC16F877. I have an extensive background in PLC (ladder logic) and VB programming. Curious, what is the difference in a PLC and a PIC, seems the memory is comparable, how about the other aspects, outside of the physical differences like terminals, programming methods, etc, all of which can be added to a PIC. 1) Is a PIC faster or slower than an Allen Bradley Micrologix-1500 LRP processor, assuming a crystal frequency of 20Mhz for the PIC? http://www.ab.com/plclogic/micrologix/1500 link to the ML-1500 PLC 2) Is a PIC as reliable and robust as a PLC, assuming good code writing skills? 3) Any disadvantages to using a PIC in the place of a PLC for a product that will only undergo manufacturer code changes? A PIC seems as if it could easily take the place of a PLC for an application that doesn't require the flexibility PLC's offer, like a project that can be developed once and recreated on a large scale. Where am I going wrong, seems to simple of an answer, and since a PIC is FAR less expensive as compared to a PLC. Thanks, Eric (first post) |
|
|
PLC vs PIC
Started by ●December 15, 2004
Reply by ●December 16, 20042004-12-16
|
Hi, >I'm fairly new to PIC microcontrollers and have been experimenting <BR> >for the last month or so with a PIC16F877. I have an extensive <BR> >background in PLC (ladder logic) and VB programming. Curious, what is >the difference in a PLC and a PIC, seems the memory is comparable, <BR> >how about the other aspects, outside of the physical differences like >terminals, programming methods, etc, all of which can be added to a >PIC. To simplify the things, we can say that the PIC (the microcontroller in general) is the heart of the PLC. That means that if you want to "build" a PLC you can take some microntroller and put the peripherial parts around it. Reley's for the outputs, some voltage converters to make the input voltage proper for the microcontroller inputs (this usually refers to AD/DA i/o), some interface chips, LED/LCD drivers etc. The PLCs usually have limited number of input and output pins, the PICs have the same thing but you can configure the i/o pins the way you want. This is not a crucial thing because you can always by another PLC or PIC deppending on your needs and funds. From the programming point of view for PICs you have assembly, pascal, basic, c... There is no ledder logic but it's really simple. Almost every block from the ledder is a assembly mnemonic (except some complex blocks, PID control for example). The proramming logic is more or less the same. >1) Is a PIC faster or slower than an Allen Bradley Micrologix-1500 >processor, assuming a crystal frequency of 20Mhz for the PIC? deppends on which PIC you'll base youre device, check www.microchip.com >2) Is a PIC as reliable and robust as a PLC, assuming good code <BR> >writing skills? Yes, but usually no. The thing is simple. If you buy a PLC you get the whole hardware that works correctly and you can concentrate on your program, the logic that you should do. Writing software for a complex sistem as PLC based on PIC is not easy job and it's time demanding. The main question is if you put all parts together on a PIC system will it work as it should be working. The second thing is that you have to write code for communication with every interface chip separately, what is not a trivial thing to do + every new design with a new component means more headackes (writing drivers, testing....). And then when everything's ok you can write your code. I've been working with PICs and PLCs for the last 5 years and sometimes when I'm making some pic device I say to my self I wish I had a PLC :) I know it sounds weird but when I use a PLC I deploy the devices faster and with less headackes. From the other side PIC devices are less expensive. > Any disadvantages to using a PIC in the place of a PLC for a >product that will only undergo manufacturer code changes? Use of PLC makes the things much more easier... upgrading, reprogramming, reliability.... >A PIC seems as if it could easily take the place of a PLC for an >application that doesn't require the flexibility PLC's offer, like a >project that can be developed once and recreated on a large scale. >Where am I going wrong, seems to simple of an answer, and since a PIC >is FAR less expensive as compared to a PLC. Yes, but it depens on your needs. The PIC is just the heart of the PLC, when you make a calculations of costs of a PIC based device and a PLC device that do the same job you'll se that the PLC device is a little bit more expencive but you can finish the device faster since you have ready to go hardware system. Cheers, Jovan |
|
|
Reply by ●December 16, 20042004-12-16
|
Hi- Just a couple of points to add to the fine reply from Jovan. For the past couple of months, I've been midnight engineering a couple of PLC designs using the PIC as the embedded controller for the hardware. I'd like to share a couple of points. 1. There is a fairly primitive PLC "ladder logic" design template package available for the PIC that is free. This is for only VERY SIMPLE ladder designs. It is designed to use the older 16F84 chips, but the output code can be easily adapated to use the newer chips (like the 16F648As) and the like. The downside is that one cannot recover the two i/o pins by going to the internal clock (darn it). So, you are very limited to the number of configurable inputs and outputs. But for very simple things, it can work. You can find the link at: http://members1.chello.nl/~f.vdburgh/picbit/inhalt.htm 2. What I have done is taken an existing PLC's ladder gui program and reverse engineered it. The ladder logic compiler that I use has its output in "binary". I did lots and lots of little one and two rung programs and looked at the binary output file. I then determined the operational characteristics of the PLC. Not really all that tough a task. Took only a couple of days. 3. I then built a small (800 lines ish) perl script to read the binary output file from the ladder logic compiler and convert it into a set of macro calls for the microchip assembler. Again, this wasn't all that tough. Maybe a week of fiddling around. 4. Built and tested the macro routines in the microchip assembler. I did most of the testing of the macros in the simulator. 5. Built the surrounding code for the PIC based PLC. I followed the usuall convention of input phase, rules phase, output phase, and repeat. 6. Using the internal clock, it takes on average about 1 microsecond per macro call for the simple logic equasions. The multiply and divide routines, of course, take much more as does the BCD to binary and binary to BCD routines (which are acutally calls to a common subroutine). Here you have to balance the logic function against the code space of the macro. With primitive functions, it can take less space (and time) to do the code in line. For more complex functions, it's better to have calls. These are just the normal implementation tradeoffs everybody has to make. 7. In making a general purpose PLC out of a PIC based design, the cost is NOT in the PIC, rather, believe it or not, in the interface hardware. The cost of the screw connectors from Digikey far outweighs the cost of the PIC! 8. For a ladder logic compiler, you might want to look at adapting the open source ladder compilers available through sourceforge. I might switch over to them myself. But not at this time. I built this toolchain for my own uses. I have a design that works well as a $5.00 DC input DC output device. 12-28V DC is pretty much the same with opto-isolators in line. 110-220AC is a little more. Haven't done the TRIAC outputs for AC yet, Still using cheap ($1.75 each) relays. The design seems to work well for me. It's really kind of a kick. I have a ladder logic control circuit on a protoboard that is only the PIC, a cap, a DIP switch and a collection of LED's and resistors. That's all it takes for a PLC. Hope that these observations helps with your efforts. Cheers, Rich S. --- In , "Jovan Kostovski" <chombium@f...> wrote: > Hi, > > >I'm fairly new to PIC microcontrollers and have been experimenting <BR> > >for the last month or so with a PIC16F877. I have an extensive <BR> > >background in PLC (ladder logic) and VB programming. Curious, what is >the difference in a PLC and a PIC, seems the memory is comparable, <BR> > >how about the other aspects, outside of the physical differences like >terminals, programming methods, etc, all of which can be added to a >PIC. > > To simplify the things, we can say that the PIC (the microcontroller in general) is the heart of the PLC. That means that if you want to "build" > a PLC you can take some microntroller and put the peripherial parts around it. Reley's for the outputs, some voltage converters to make the input voltage proper for the microcontroller inputs (this usually refers to AD/DA i/o), some interface chips, LED/LCD drivers etc. > The PLCs usually have limited number of input and output pins, the PICs have the same thing but you can configure the i/o pins the way you want. > This is not a crucial thing because you can always by another PLC or PIC deppending on your needs and funds. > > From the programming point of view for PICs you have assembly, pascal, basic, c... There is no ledder logic but it's really simple. Almost every block from the ledder is a assembly mnemonic (except some complex blocks, PID control for example). > The proramming logic is more or less the same. > > >1) Is a PIC faster or slower than an Allen Bradley Micrologix-1500 > >processor, assuming a crystal frequency of 20Mhz for the PIC? > > deppends on which PIC you'll base youre device, check www.microchip.com > > >2) Is a PIC as reliable and robust as a PLC, assuming good code <BR> > >writing skills? > > Yes, but usually no. The thing is simple. If you buy a PLC you get the whole hardware that works correctly and you can concentrate on your program, the logic that you should do. Writing software for a complex sistem as PLC based on PIC is not easy job and it's time demanding. > The main question is if you put all parts together on a PIC system will it work as it should be working. The second thing is that you have to write code for communication with every interface chip separately, what is not a trivial thing to do + every new design with a new component means more headackes (writing drivers, testing....). And then when everything's ok you can write your code. > I've been working with PICs and PLCs for the last 5 years and sometimes when I'm making some pic device I say to my self I wish I had a PLC :) > I know it sounds weird but when I use a PLC I deploy the devices faster and with less headackes. From the other side PIC devices are less expensive. > > > Any disadvantages to using a PIC in the place of a PLC for a > >product that will only undergo manufacturer code changes? > > Use of PLC makes the things much more easier... > upgrading, reprogramming, reliability.... > > >A PIC seems as if it could easily take the place of a PLC for an > >application that doesn't require the flexibility PLC's offer, like a >project that can be developed once and recreated on a large scale. > >Where am I going wrong, seems to simple of an answer, and since a PIC >is FAR less expensive as compared to a PLC. > > Yes, but it depens on your needs. The PIC is just the heart of the PLC, > when you make a calculations of costs of a PIC based device and a PLC device that do the same job you'll se that the PLC device is a little bit more expencive but you can finish the device faster since you have ready to go hardware system. > > Cheers, Jovan |
|
|
Reply by ●December 16, 20042004-12-16
|
Thanks Jovan & Rich for the quick replies and good information. I do NOT want to program a PIC with ladder logic; I purchased the PicBasic Pro compiler in which I'm learning very quickly due to my VB experience. After all, I've spent more time with VB than my wife, and therefore know it better than her ;-). To cut to the chase, I am currently using a MicroLogix-1500 PLC as described in the previous post on a regular basis, each containing the same code for a product that is in production. This unit cost about $1400 (OEM Pricing) per unit and collectively consist of 18 digital inputs, 8 digital outs, 4 analog inputs, and 2 analog outs (14-bit resolution). The processor has two serial (DB9) communication ports and a maximum program memory of 12k x 16bit words, of which, 4k can be used for data tables (variables). Our application consumes about 10k of the 12k memory, I wrote a small routine to calculate the scan time with the current program and it clocks at about 83 SPS, or 83 complete scans per second. In a PLC that is, Inputs are read, code is scanned, and finally the outputs are written 83 times per second for a program of this size and content. I originally bought the PIC starter package from MELabs to start using PIC's for a smaller scale product. Then wondered if I could use a PIC in place of the MicroLogic-1500 PLC. R&D is not an issue; my main concern is processing speed and capacity of a PIC, as compared to the PLC. Jovan wrote: Speed, "deppends on which PIC you'll base youre device, check www.microchip.com". Lets assume I will use any PIC that will do the job, will any PIC do the job of a MicroLogix-1500, or is this out of the league of any PIC in terms of computing power? Remember, I do not need the flexibility of a PLC's programming or hardware features, this product will be produced once and duplicated many times. The goal is to save money in reproduction cost, yet allow the machine to function the same. Is a PIC with the proper supporting components up to the task? Thanks, Eric |
|
|
Reply by ●December 16, 20042004-12-16
|
At 02:41 PM 12/16/2004, pondindustrial wrote: >Lets assume I will use any PIC that will do the job, will any PIC do >the job of a MicroLogix-1500, or is this out of the league of any PIC >in terms of computing power? >Remember, I do not need the flexibility of a PLC's programming or >hardware features, this product will be produced once and duplicated >many times. The goal is to save money in reproduction cost, yet allow >the machine to function the same. Is a PIC with the proper supporting >components up to the task? Absolutely YES. All the hard work is going to be in the compiler end of things - the application running on the PC that is taking in your ladder logic and turning it into state machines that run on the PIC. Eliminate the ladder logic end of things and you have something that many of us do on a regular basis: write your application in Assembler or a high-level language of your choice. I can give a specific example: the card set we use in some of our industrial process ovens is based on a PIC 16c73b running at 4 MHz (1 MIPS). The card set consists of several cards. The main card contains: 7 user controllable SPDT relays, output drivers for 6 more off-board relays, 14- 8-bit a/d inputs, 1- RS-232 port, 1- custom 1-wire network port for communications between 62 other card sets 2- 8 position dip switches 8 wire buss that goes off to the display card 14 pin ribbon header for LCD display power supply (24 Vac CT input) The optional daughter card that sits on top of the main card adds 14 more a/d inputs, 8 more SPDT relays and 2 more 8-position dip switches. The display card contains 40 LEDs, 7- trinary switch inputs (connect to SPDT center-off switches), a ribbon header that goes off to a small numeric display card with up to 3 digits of 7-segment displays and another ribbon header used to connect multiple multiple systems together. The software originally written for the customer's application was done as a background / foreground cooperative muli-tasking application. The background task looks after all I/O processes: getting a/d readings, controlling all the relays & LEDs, managing all the communications. The background task uses about 200 us out of each 1024 us time tick. The remaining 800 us is available to the foreground tasks. Just for giggles and laughs, I took a completely different application originally written for an A-B slc500 PLC system and implemented it on our card set. Each major task in the original ladder diagram was implemented as a state machine running in the foreground on my PIC system. I think I wound up with 15 or 20 state machines all running concurrently. Because the background task took care of all the I/O, making the original application run on this card set took surprisingly little effort. One interesting consequence was that the effective loop time went from tens of ms down to the 1.024 ms tick rate of the background task. In other words, not only was it MUCH less expensive to produce, it was faster! The down sides were several but minor: 1) end user can't change the code - the 16c73 is an OTP part. Some might see that as a benefit. 2) Your typical electrician can't write the code him/herself. They can write it in ladder form and send it to us but they don't usually work in PIC assembler themselves. That means that quick changes in the field don't happen unless we are out there with the unit. 3) Failures / mistakes happen. The end user can't call up their local A-B distributor and just order in a new PLC when a conveyor line breaks and dumps a two ton block of metal on top of the control cabinet or when the local electrician accidently drops one leg of 600V feeder onto a 17V limit switch connection. (I've seen both of the those as well as other interesting failures). We dealt with failures by including spare cards with each system. The cost of a set of spare cards was much less than the cost of the equivalent A-B PLC. Hope this helps! dwayne -- Dwayne Reid <> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 20 years of Engineering Innovation (1984 - 2004) .-. .-. .-. .-. .-. .-. .-. .-. .-. .- `-' `-' `-' `-' `-' `-' `-' `-' `-' Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. |
|
|
Reply by ●December 16, 20042004-12-16
|
Dwayne, Wow, you hit the nail on the head! I was under the impression PIC's were sluggish compared to PLC's. To be honest, I got this impression after searching the web for PIC projects and found nothing more than trivial, hobby oriented stuff (not that there's anything wrong with hobby projects). I did run some minor speed test of my own on a PIC16F877, I simply created a For Loop and incremented a variable to 50k, turned on a LED, paused for one second, then turned the LED off, reset the counter to zero, then did it over again, and again. The time between illuminations was quick considering; from there I couldn't understand why I didn't find any processor demanding applications as a result of my Goggle searches I did a quick tally of parts to recreate the functionality of the ML- 1500 PLC combination (I/O cards etc.) using a PIC, it came out to less than $100 per controller, depending on quantity. This included a two layer PCB at a quantity of 100 per order assuming we stuffed and soldered the PCB's ourselves, although I didn't include labor. Does this sound correct? Thanks, Eric --- In , Dwayne Reid <dwayner@p...> wrote: > At 02:41 PM 12/16/2004, pondindustrial wrote: > > >Lets assume I will use any PIC that will do the job, will any PIC do > >the job of a MicroLogix-1500, or is this out of the league of any PIC > >in terms of computing power? > >Remember, I do not need the flexibility of a PLC's programming or > >hardware features, this product will be produced once and duplicated > >many times. The goal is to save money in reproduction cost, yet allow > >the machine to function the same. Is a PIC with the proper supporting > >components up to the task? > > Absolutely YES. > > All the hard work is going to be in the compiler end of things - the > application running on the PC that is taking in your ladder logic and > turning it into state machines that run on the PIC. > > Eliminate the ladder logic end of things and you have something that many > of us do on a regular basis: write your application in Assembler or a > high-level language of your choice. > > I can give a specific example: the card set we use in some of our > industrial process ovens is based on a PIC 16c73b running at 4 MHz (1 > MIPS). The card set consists of several cards. > > The main card contains: > 7 user controllable SPDT relays, > output drivers for 6 more off-board relays, > 14- 8-bit a/d inputs, > 1- RS-232 port, > 1- custom 1-wire network port for communications between 62 other card sets > 2- 8 position dip switches > 8 wire buss that goes off to the display card > 14 pin ribbon header for LCD display > power supply (24 Vac CT input) > > The optional daughter card that sits on top of the main card adds 14 more > a/d inputs, 8 more SPDT relays and 2 more 8-position dip switches. > > The display card contains 40 LEDs, 7- trinary switch inputs (connect to > SPDT center-off switches), a ribbon header that goes off to a small numeric > display card with up to 3 digits of 7-segment displays and another ribbon > header used to connect multiple multiple systems together. > > The software originally written for the customer's application was done as > a background / foreground cooperative muli-tasking application. The > background task looks after all I/O processes: getting a/d readings, > controlling all the relays & LEDs, managing all the communications. The > background task uses about 200 us out of each 1024 us time tick. The > remaining 800 us is available to the foreground tasks. > > Just for giggles and laughs, I took a completely different application > originally written for an A-B slc500 PLC system and implemented it on our > card set. Each major task in the original ladder diagram was implemented > as a state machine running in the foreground on my PIC system. I think I > wound up with 15 or 20 state machines all running concurrently. > > Because the background task took care of all the I/O, making the original > application run on this card set took surprisingly little effort. One > interesting consequence was that the effective loop time went from tens of > ms down to the 1.024 ms tick rate of the background task. In other words, > not only was it MUCH less expensive to produce, it was faster! > > The down sides were several but minor: > > 1) end user can't change the code - the 16c73 is an OTP part. Some might > see that as a benefit. > > 2) Your typical electrician can't write the code him/herself. They can > write it in ladder form and send it to us but they don't usually work in > PIC assembler themselves. That means that quick changes in the field don't > happen unless we are out there with the unit. > > 3) Failures / mistakes happen. The end user can't call up their local A-B > distributor and just order in a new PLC when a conveyor line breaks and > dumps a two ton block of metal on top of the control cabinet or when the > local electrician accidently drops one leg of 600V feeder onto a 17V limit > switch connection. (I've seen both of the those as well as other > interesting failures). > > We dealt with failures by including spare cards with each system. The cost > of a set of spare cards was much less than the cost of the equivalent A-B PLC. > > Hope this helps! > > dwayne > > -- > Dwayne Reid <dwayner@p...> > Trinity Electronics Systems Ltd Edmonton, AB, CANADA > (780) 489-3199 voice (780) 487-6397 fax > > Celebrating 20 years of Engineering Innovation (1984 - 2004) > .-. .-. .-. .-. .-. .-. .-. .-. .-. .- > `-' `-' `-' `-' `-' `-' `-' `-' `-' > Do NOT send unsolicited commercial email to this email address. > This message neither grants consent to receive unsolicited > commercial email nor is intended to solicit commercial email. |
|
|
Reply by ●December 16, 20042004-12-16
|
Is UL Listing a consideration? CE mark? --- In , "pondindustrial" <pondindustrial@y...> wrote: > > Dwayne, > > Wow, you hit the nail on the head! > > I was under the impression PIC's were sluggish compared to PLC's. To > be honest, I got this impression after searching the web for PIC > projects and found nothing more than trivial, hobby oriented stuff > (not that there's anything wrong with hobby projects). I did run some > minor speed test of my own on a PIC16F877, I simply created a For > Loop and incremented a variable to 50k, turned on a LED, paused for > one second, then turned the LED off, reset the counter to zero, then > did it over again, and again. The time between illuminations was > quick considering; from there I couldn't understand why I didn't find > any processor demanding applications as a result of my Goggle > searches > > I did a quick tally of parts to recreate the functionality of the ML- > 1500 PLC combination (I/O cards etc.) using a PIC, it came out to > less than $100 per controller, depending on quantity. This included a > two layer PCB at a quantity of 100 per order assuming we stuffed and > soldered the PCB's ourselves, although I didn't include labor. > > Does this sound correct? > > Thanks, Eric > --- In , Dwayne Reid <dwayner@p...> wrote: > > At 02:41 PM 12/16/2004, pondindustrial wrote: > > > > >Lets assume I will use any PIC that will do the job, will any PIC > do > > >the job of a MicroLogix-1500, or is this out of the league of any > PIC > > >in terms of computing power? > > >Remember, I do not need the flexibility of a PLC's programming or > > >hardware features, this product will be produced once and > duplicated > > >many times. The goal is to save money in reproduction cost, yet > allow > > >the machine to function the same. Is a PIC with the proper > supporting > > >components up to the task? > > > > Absolutely YES. > > > > All the hard work is going to be in the compiler end of things - > the > > application running on the PC that is taking in your ladder logic > and > > turning it into state machines that run on the PIC. > > > > Eliminate the ladder logic end of things and you have something > that many > > of us do on a regular basis: write your application in Assembler or > a > > high-level language of your choice. > > > > I can give a specific example: the card set we use in some of our > > industrial process ovens is based on a PIC 16c73b running at 4 MHz > (1 > > MIPS). The card set consists of several cards. > > > > The main card contains: > > 7 user controllable SPDT relays, > > output drivers for 6 more off-board relays, > > 14- 8-bit a/d inputs, > > 1- RS-232 port, > > 1- custom 1-wire network port for communications between 62 other > card sets > > 2- 8 position dip switches > > 8 wire buss that goes off to the display card > > 14 pin ribbon header for LCD display > > power supply (24 Vac CT input) > > > > The optional daughter card that sits on top of the main card adds > 14 more > > a/d inputs, 8 more SPDT relays and 2 more 8-position dip switches. > > > > The display card contains 40 LEDs, 7- trinary switch inputs > (connect to > > SPDT center-off switches), a ribbon header that goes off to a small > numeric > > display card with up to 3 digits of 7-segment displays and another > ribbon > > header used to connect multiple multiple systems together. > > > > The software originally written for the customer's application was > done as > > a background / foreground cooperative muli-tasking application. > The > > background task looks after all I/O processes: getting a/d > readings, > > controlling all the relays & LEDs, managing all the > communications. The > > background task uses about 200 us out of each 1024 us time tick. > The > > remaining 800 us is available to the foreground tasks. > > > > Just for giggles and laughs, I took a completely different > application > > originally written for an A-B slc500 PLC system and implemented it > on our > > card set. Each major task in the original ladder diagram was > implemented > > as a state machine running in the foreground on my PIC system. I > think I > > wound up with 15 or 20 state machines all running concurrently. > > > > Because the background task took care of all the I/O, making the > original > > application run on this card set took surprisingly little effort. > One > > interesting consequence was that the effective loop time went from > tens of > > ms down to the 1.024 ms tick rate of the background task. In other > words, > > not only was it MUCH less expensive to produce, it was faster! > > > > The down sides were several but minor: > > > > 1) end user can't change the code - the 16c73 is an OTP part. Some > might > > see that as a benefit. > > > > 2) Your typical electrician can't write the code him/herself. They > can > > write it in ladder form and send it to us but they don't usually > work in > > PIC assembler themselves. That means that quick changes in the > field don't > > happen unless we are out there with the unit. > > > > 3) Failures / mistakes happen. The end user can't call up their > local A-B > > distributor and just order in a new PLC when a conveyor line breaks > and > > dumps a two ton block of metal on top of the control cabinet or > when the > > local electrician accidently drops one leg of 600V feeder onto a > 17V limit > > switch connection. (I've seen both of the those as well as other > > interesting failures). > > > > We dealt with failures by including spare cards with each system. > The cost > > of a set of spare cards was much less than the cost of the > equivalent A-B PLC. > > > > Hope this helps! > > > > dwayne > > > > -- > > Dwayne Reid <dwayner@p...> > > Trinity Electronics Systems Ltd Edmonton, AB, CANADA > > (780) 489-3199 voice (780) 487-6397 fax > > > > Celebrating 20 years of Engineering Innovation (1984 - 2004) > > .-. .-. .-. .-. .-. .-. .-. .-. .-. .- > > `-' `-' `-' `-' `-' `-' `-' `-' `-' > > Do NOT send unsolicited commercial email to this email address. > > This message neither grants consent to receive unsolicited > > commercial email nor is intended to solicit commercial email. |
|
|
Reply by ●December 16, 20042004-12-16
|
while I'm a fan of doing something like this, one of the things you are paying for with an industrial controller like this is all the reliability engineering that goes into it. Its pretty easy to build a system that mimics the PLC but industrial environments are electrically very noisy places. Good engineering practices and extensive testing are a must. The device has to handle some pretty wild stuff. A company that serves the market had better have their act together on that front (or sink beneath the waves...). I'm not saying "Dont", just know what you're getting into. The good news is that there has to be a ton of profit margin to attack there. |
Reply by ●December 17, 20042004-12-17
|
At 07:55 PM 12/16/2004, pondindustrial wrote: >Dwayne, > >Wow, you hit the nail on the head! > >I was under the impression PIC's were sluggish compared to PLC's. To >be honest, I got this impression after searching the web for PIC >projects and found nothing more than trivial, hobby oriented stuff >(not that there's anything wrong with hobby projects). I did run some >minor speed test of my own on a PIC16F877, I simply created a For >Loop and incremented a variable to 50k, turned on a LED, paused for >one second, then turned the LED off, reset the counter to zero, then >did it over again, and again. The time between illuminations was >quick considering; from there I couldn't understand why I didn't find >any processor demanding applications as a result of my Goggle >searches > >I did a quick tally of parts to recreate the functionality of the ML- >1500 PLC combination (I/O cards etc.) using a PIC, it came out to >less than $100 per controller, depending on quantity. This included a >two layer PCB at a quantity of 100 per order assuming we stuffed and >soldered the PCB's ourselves, although I didn't include labor. > >Does this sound correct? Sounds close, depending upon how much I/O you need. I'd look to using TPIC6595 power shift registers for relay drivers; we use Aromat JS1 relays on our cards, we used 4051 analog muxes to get all the a/d inputs we needed. Watch out when using standard CMOS analog muxes: you get severe cross-channel coupling if any input goes above or below the supply rails. This was a problem in our units: allowable analog input was 0...5V but a faulty thermocouple transmitter could exceed 5V easily. We dealt with it by treating dedicating two out of the 16 channels on each of the main and daughter cards to known voltages: if those channels were not correct, fault the system to a known safe state. I've looked at muxes that are immune to that problem but they seem to come from only Maxim and those guys have caused us grief with allocation problems in the past. Doesn't mean I won't use Maxim parts - just means I budget for a year's worth of their inventory sitting on our shelf - just in case. We used 24Vac CT as our supply: the center tap gave us 12Vac which is half-wave rectified to about 15 Vdc - relays & all LEDs operate from that unregulated supply. 5V rail is from a LP2950A precision low-power regulator - it has 0.5% initial accuracy and was more than adequate as the reference for our a/d inputs. Our total 5V current consumption was only about 20 mA and the LP2950 runs cold which improves its accuracy. All of the a/d inputs we needed were for temperature inputs that don't change very fast - we simply used 10K series resistors and 1uF tant filter caps on each input going into the muxes. We made provision for shunt resistors right at the mux inputs in case we wanted to handle higher input voltages. All our a/d inputs also had shunt resistors right at the input terminals to deal with our thermocouple transmitters (temperature to current transmitters). The input shunt resistors were sized so that the current corresponding to the highest temperature each input would ever see was somewhat below 5V. The transmitters were powered from the same un-regulated 15V supply as all the other high-current stuff - they have excellent PSRR characteristics and the power supply ripple was not measurable at the a/d inputs. Slow speed digital inputs & dip switches are handled with 4021 shift registers clocked at the same time as the TPIC output shift registers. The few high-speed lines we needed go straight into the PIC after some simple but effective protection networks. Most standard PIC16 family parts have an on-board UART - we included a MAX-232 on board so that we have a real serial port. The one-wire communications buss for system-wide communications I mentioned was bit-banged at the same time as the shift register stuff - this gave us a slow speed but extremely robust link that we used for system-wide messages. That buss also ties into a card we call a communications controller - intended to be used with a modem for remote diagnostics and such. That was the plan - fact is, I don't think we ever did hook a modem to any of the systems. About the only use that buss ever saw was to set up calibration constants and operational defaults stored on eeprom and to get stored fault data when a failure was serious enough that a tech had to visit the site. Forgot to mention: our card also included a Xicor X5043 power supply supervisor / power-up reset controller / watchdog / 512 byte eeprom. The reset line from that part also went to a hardware lockout timer that completely disables any critical outputs in hardware: it removes coil power from a bunch of the relays on the main card as well as disabling 24VAC output from the card. Any auxiliary cards that were part of our board set included their own 5V power supply derived from the un-regulated supply. This reduced the chance that a problem on one card would affect the main card which made diagnostics easier. All lines that connect auxiliary cards to the main card were protected against contact with the un-regulated supply - intended to protect against fumble-fingered electricians (no offense intended - sh*t happens). All un-regulated lines and the 24Vac outputs were all protected with self-resetting Polyswitch current limit devices. This made easy work of the most common problems we had to trouble-shoot by phone - just told the tech on site to carefully touch each of the gold-colored discs - the hot spot pointed to the trouble area. Most problems were outside of the cabinet - either sensors (often) or thermocouples (occasionally) or TC transmitters (rarely). I hope the above rambling helps in some way. You need to think about what happens when something goes wrong - how do you protect the equipment you are controlling as well as the controller itself. You need to make it easy for any electrician to trouble-shoot and fix. You need to be able to get enough information from the displays to that you can help fix it over the phone. dwayne -- Dwayne Reid <> Trinity Electronics Systems Ltd Edmonton, AB, CANADA (780) 489-3199 voice (780) 487-6397 fax Celebrating 20 years of Engineering Innovation (1984 - 2004) .-. .-. .-. .-. .-. .-. .-. .-. .-. .- `-' `-' `-' `-' `-' `-' `-' `-' `-' Do NOT send unsolicited commercial email to this email address. This message neither grants consent to receive unsolicited commercial email nor is intended to solicit commercial email. |
Reply by ●December 17, 20042004-12-17
|
Hi Eric- --- In , "pondindustrial" <pondindustrial@y...> wrote: > > Thanks Jovan & Rich for the quick replies and good information. > > I do NOT want to program a PIC with ladder logic; I purchased the > PicBasic Pro compiler in which I'm learning very quickly due to my VB > experience. After all, I've spent more time with VB than my wife, and > therefore know it better than her ;-). > Opps! My bad. O.K. if you want to whomp up some compiled code, in general you will find that the code will run faster than the equivalent ladder-logic code implemetation. As mentioned in one of the other fine replies, there is one of us who is using it to replace a PLC application. He mentioned that he is running it at 4MHz. The standard 16F877 can be run with a 20MHz crystal yielding a 5 times increase in speed. You do loose a couple of I/O pins. I would NOT worry about the number of I/O pins on the PIC. Usually, one finds that one is always wanting JUST ONE MORE I/O pin. In practice, you can easily increase the number of I/O pins with simple multiplexing logic and latches and input buffers. The good old '244 and '373 buffers and latches with a '138 usually does me fine. Others like to shift data into and out of serial shift registers. That's fine too. As far as reliability is concerned, well, you are rolling out the design. You are the one that has to make the tradeoffs. A standard PLC is usually (as you know) designed for industrial applications with enough safeguards to provide an adequate job of protection vs. cost. Things like master relays aren't there in a PIC (unless you design them in). Things like the watch dog timer can go a long way in helping plan for the unexpected. My suggestion is to code up the application (or a part of it) and see if the resulting code/hardware will meet you timing applications (with a safety factor of, oh, 2 or so). You can (usually) eaily prototype up something to model your hardware to match. As far as the available literature out there being geared for hobbiests, you are most likely right. This is a processor that lends itself very well to hobby type applications. I've designed devices for my hobby using the pic for: 1. Photographic timer for my darkroom. 2. 100MHz frequency counter. 3. "You've got mail" display on the desk in the front room. 4. EEPROM programmer. 5. Stepper motor controller. These are the HOBBY side. The other side, well, gee, mumble, mumble (you get the idea). I found the pic a couple of years ago. I wanted to do a contoller for a simple family radio service box. I yanked out my MSI logic book and started the pencil pushing. I said "There has to be a better way by this time" and started looking. The pic vs atmel decision was based upon the wide variety of microchip chips. I could have easily gone the other way (gone to the dark side?). BUT, for only a couple of bucks, a free assembler, and a home rolled programmer (from the Ottowa Robotics Society), I was ready to rock and roll. Because of the single chip design, I could do prototypes on those push in prototyping boards (something I would NOT do with a high chip count design). So, yes, it's a hobbiest's dream come true. But, we often don't talk about what we use the PICs for in the paid world. Most of the time, it would not be germain to too many people anyway. The hobby stuff has a much larger audience. Cheers, Rich S. |
|
|
