|
Hi, >Is UL Listing a consideration? CE mark? Very good point, although we will have our PIC based controller UL listed upon completion, along with the rest of the system. If anyone is curious about the application, our website can be found here. http://www.pondpcs.com Thanks, Eric --- In , "rtstofer" <rstofer@p...> wrote: > > > 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. |
PLC vs PIC
Started by ●December 15, 2004
Reply by ●December 17, 20042004-12-17
Reply by ●January 5, 20052005-01-05
|
----- Original Message ----- From: "Allan Lane" <> To: <> Sent: Wednesday, January 05, 2005 8:20 PM Subject: [piclist] Re: Quadrature Encoders > > > I would think a 'bouncing' quadrature encoder would > be pretty useless. That's why we don't make them > out of switches (which bounce). Most encoders I've > seen are visible (using reflecting IR led's or such) > and produce non-bouncing outputs. The widely used low-cost encoders made by ALPS use switches, and they bounce. Leon -- |
Reply by ●January 5, 20052005-01-05
|
Thanks guys. That's pretty much what I thought. I don't have an oscope, and I'm having a hard-time understanding what I'm seeing w/o one, and frankly I am grasping at straws right now. I have a quadrature encoder that is connected to a motor shaft directly; there is no gearing between the encoder and the motor shaft. The encoder is a 1440 ticks per revolution encoder. I have channels A and B hooked up to some port B pins on a PIC that have the interrupt on change feature. I have a counter that I set to the number of ticks I want to move the motor, enable interrupts for port B, and start the motor moving. In the interrupt handler I then: 1. Read port B to remove any mismatch condition, 2. Clear the RCIF flag in INTCON, 3. dec the counter, and if it's zero, then I, 4. stop/brake the motor and disable interrupts on port B, otherwise 5. just return from the interrupt. The problem is that if I set the counter to 1440-decimal, then the motor hardly moves at all, but I know the counter is being decremented to zero because I have verified this. If I set the counter to like 9000-hex, then I can get the motor shaft to move one full revolution, but only in one direction. In the other direction it will only move about 1/2 of a revolution. It's like I'm getting too many interrupts, but by different amounts in each direction. I could only surmise that maybe the output of the encoder channels was "noisy" or something like that. Any ideas appreciated. Maybe I'm just making some fatal n00bie assumption on how this should work. I don't really care to count the gray-code coming from the encoder channels, in order to determine direction. I know which direction the motor is turning, since I started it turning in the desired direction, and there is not enough torque in the system for it to not possibly turn smoothly in the direction I want. I just want to count how many ticks the shaft has rotated, and stop it when it has gone the required amount. Take Care, --- In , Eirik Karlsen <eikarlse@o...> wrote: > They need not be debounced. Transitions are not smooth but infact sharp > and clean... > this is the general rule for optical encoders with digital output. > However some encoders > does not have a digital output as they're sending out more or less raw > signal form the > sensors, output may look like 'soft square' or even sinewave at higher > frequencies... > IMHO these are more difficult to use. > > There are rotary shaft encoders, or rotary switches, with quadrature > output. These come in > optical and mechanical versions, the mechanical ones may need > debouncing. > > cjl023 wrote: > > > > > Hello, > > > > Does anyone know if quadrature encoders (like say the ones made by > > US Digital) need to be debounced, or do the A and B channels provide > > nice smooth transitions from low-to-high and vice-versa? > > > > Thanks, > > > > > > > > > > > > > > to unsubscribe, go to http://www.yahoogroups.com and follow the > > instructions > > > > > > > [click here] > > > > > ------------------------- -- > > Yahoo! Groups Links > > > > * To > > > -- > ******************************************* > VISIT MY HOME PAGE: > <http://home.online.no/~eikarlse/index.htm> > LAST UPDATED: 23/08/2003 > ******************************************* > Regards > Eirik Karlsen |
Reply by ●January 5, 20052005-01-05
|
You say "and stop it when it has gone the required amount."
what you are proposing is actually a sevosystem, and that will require both 'speed & direction' feedback, and also 'speed & direction' output to the motor. If you've said "and cut power to it when it has gone the required
amount."
cjl023 wrote:
--
|
|
|
Reply by ●January 5, 20052005-01-05
|
Hi- Comments in line: Well, I was born in '53, so I've still got a ways to go before I retire. Besides, I like what I'm doing. --- In , "rtstofer" <rstofer@p...> wrote: ---------------------------<snip>------------------------------- > > Xilinx Spartan 3 Starter Board which will work, although it is not > the board I am using, costs $100. Free development software, etc. > If you ever liked doing logic design, these things are a kick! > Imagine being able to work with 200,000 or 300,000 gates! Can you > imagine the heat if you used 74xx? And the amount of wire-wrapping > on 75,000 packages? > Yep. I use some of the bigger Xilinx chips here at work. They are indeed fun to work with. Using mentor at this shop. Not as much fun. I've been thinking seriously of the evaluation board that you mentioned, along with the free software. There are some designs where an FPGA is real nice to have. Unfortunately, I don't have Mentor (and it's 10K price tag) at home. But am seriously considering as you mentioned. Most of the stuff that I've been playing with has timing contraints of 100's of microseconds, perfect for some real time programming with the PIC. But the $100 investment (along with the hours and hours of fun) learning the Spartan class of FPGAs is well worthwhile. That way, when this job is over, I can still have a toolset for FPGA design. ---------------------------<snip>------------------------------- > The sector blocking and deblocking is done in the BIOS so CP/M isn't > even aware of it. CP/M deals in 128 bytes sectors, only. > > Now, as it turns out, I couldn't get 8 bit transfer to work, the Z80 > core is an 8 bit machine so I just ignored the high 8 bits of every > word. This results in 256 bytes per physical sector so there is a > two for one blocking/deblocking to handle. No big deal, it has been > that way since DSDD floppies. I thought we had "packed" double sided double density floppies. Now that I think back on it, it was a non-caching system where if the upper half of the sector was to be written, the sector was read, updated and written. At least somewhere along my rusty past I remember doing that. I do fondly remember cutting up the BIOS for CP/M! I built a little bit banger UART for my printer using it. In those days, there were a lot of printers that had both the centronics and an RS232 interface on them. Nowadays, I think it's all pretty much USB. > > I found every bit of CP/M source available on the Internet. My > distribution version of the project includes everything necessary to > build a complete machine (more or less automatically) once the user > downloads a few things that I don't include (questions of copyright > in my mind). But everything is freely available. > > CP/M is a nice, simple type of OS. Nothing fancy but no bloat > either. My project also includes FPGA cores for a VGA display 25x80 > and a PS/2 keyboard. > > If you are interested, I can send you the entire ZIP file - it's a > meg or so. > Sure! Go ahead and send it to: and I'll be looking for it. ---------------------------<snip>------------------------------- > > No, it is a walk in the park! You use 22NICE to emulate, on the PC, > a CP/M machine and use the distribution stuff to build the CCP > (command processor) and BDOS (disk operating system). Obviously, > you have to develop your own BIOS but that can be quite simple and > really involves following a well paved yellow brick road. Cool! Well, I think that I can still puzzle out the 8080 assembly code, and I can whomp up an RS232 driver for the console no problem. There are some demo stuff for PIC to Compact Flash, so that might be an interesting option. I don't feel like doing the floppy interface. Now, if I still have those 8 inch floppies and drives (I know I have the drives). Well, I could get wordstar up and running again! Might/would be fun to play with. I've got a Z80 with 32K of RAM already wire wrapped up. Be nothing to do a uart for it and shoot, with 32K EEPROM, I should have all sorts of room for a boot loader.... Yes, CP/M is a good little DOS. Small enough to get a handle on what you needed to do and light enough to run on very small systems. Heck, I can throw another 32K of RAM in there (shadowed of course) and have a "full blown" system. I think that it runs about $20 for the Z80, clock and memory chips at today's prices, a tad bit more with sockets. I suppose that I'll have to try doing double sided boards at home. Well, it will be fun. In fact, I might just blow the dust off the ADM3A terminal that I used to use for my cp/m machine in the late 70's! That would be ironic. If you could also toss in some instructions/links to the additional software, I would appreciate it. I did copy the cp/m 2.2 stuff a while ago when they mentioned it being available on slashdot, but did not persue it too far. I'm guessing that one uses the emulator to assemble the CPP, BDOS and BIOS for the target machine, yielding a couple of binary files. Are there utilities for putting them on media for boot up? It's kind of the chicken and the egg sort of thing. Thanks! Cheers, Rich S. |
|
|
Reply by ●January 5, 20052005-01-05
|
Eirik, I dynamically brake the DC motor by momentarily reversing the voltage applied to it for 20mS. This stops the motor dead in its tracks. I'm using a TEA3718 to control the motor, and always turn it at the slowest speed possible, when positioning it in the described manner. It's just a small 9VDC motor with a gear box that then has a shaft that comes out both sides of the gear box. One of the shafts connects to the encoder. The other shaft connects to a rack-and- pinion focusing mechanism on an optical tube. Thanks, --- In , Eirik Karlsen <eikarlse@o...> wrote: > You say "and stop it when it has gone the required amount." > what you are proposing is actually a sevosystem, and that > will require both 'speed & direction' feedback, and also > 'speed & direction' output to the motor. > > If you've said "and cut power to it when it has gone the required > amount." > things would be very simple...but the motor would almost certainly > overshoot. > > cjl023 wrote: > > > > > Thanks guys. That's pretty much what I thought. > > > > I don't have an oscope, and I'm having a hard-time understanding > > what I'm seeing w/o one, and frankly I am grasping at straws right > > now. > > > > I have a quadrature encoder that is connected to a motor shaft > > directly; there is no gearing between the encoder and the motor > > shaft. > > > > The encoder is a 1440 ticks per revolution encoder. > > > > I have channels A and B hooked up to some port B pins on a PIC that > > have the interrupt on change feature. > > > > I have a counter that I set to the number of ticks I want to move > > the motor, enable interrupts for port B, and start the motor moving. > > > > In the interrupt handler I then: > > > > 1. Read port B to remove any mismatch condition, > > > > 2. Clear the RCIF flag in INTCON, > > > > 3. dec the counter, and if it's zero, then I, > > > > 4. stop/brake the motor and disable interrupts on port B, otherwise > > > > 5. just return from the interrupt. > > > > The problem is that if I set the counter to 1440-decimal, then the > > motor hardly moves at all, but I know the counter is being > > decremented to zero because I have verified this. > > > > If I set the counter to like 9000-hex, then I can get the motor > > shaft to move one full revolution, but only in one direction. In the > > other direction it will only move about 1/2 of a revolution. > > > > It's like I'm getting too many interrupts, but by different amounts > > in each direction. I could only surmise that maybe the output of the > > encoder channels was "noisy" or something like that. > > > > Any ideas appreciated. Maybe I'm just making some fatal n00bie > > assumption on how this should work. > > > > I don't really care to count the gray-code coming from the encoder > > channels, in order to determine direction. I know which direction > > the motor is turning, since I started it turning in the desired > > direction, and there is not enough torque in the system for it to > > not possibly turn smoothly in the direction I want. I just want to > > count how many ticks the shaft has rotated, and stop it when it has > > gone the required amount. > > > > Take Care, > > -- > ******************************************* > VISIT MY HOME PAGE: > <http://home.online.no/~eikarlse/index.htm> > LAST UPDATED: 23/08/2003 > ******************************************* > Regards > Eirik Karlsen |
Reply by ●January 5, 20052005-01-05
|
Ok.
You may well have noise in the system. Use screened wire for all feedback signals, screen to proc. gnd. Also try screening the motorwires. Motordrive signals (especially PWM) are very noisy. cjl023 wrote: -- ******************************************* VISIT MY HOME PAGE: <http://home.online.no/~eikarlse/index.htm> LAST UPDATED: 23/08/2003 ******************************************* Regards Eirik Karlsen |
|
|
Reply by ●January 5, 20052005-01-05
|
Eirik, That's a good point. I'm driving the motor using a TEA3718. It drives a constant current through the motor using switch mode current regulation. The power and encoder channels all run through the same flat 6 conductor piece of cable. This is just the way the motor is put together. It comes off-the-shelf this way. Thanks for your help and counsel. I will look into isolating these cables from one another and see if it helps. Take Care, --- In , Eirik Karlsen <eikarlse@o...> wrote: > Ok. > You may well have noise in the system. Use screened wire for all > feedback signals, screen to proc. gnd. > Also try screening the motorwires. Motordrive signals (especially PWM) > are very noisy. > > cjl023 wrote: > > > > > Eirik, > > > > I dynamically brake the DC motor by momentarily reversing the > > voltage applied to it for 20mS. This stops the motor dead in its > > tracks. > > > > I'm using a TEA3718 to control the motor, and always turn it at the > > slowest speed possible, when positioning it in the described manner. > > > > It's just a small 9VDC motor with a gear box that then has a shaft > > that comes out both sides of the gear box. One of the shafts > > connects to the encoder. The other shaft connects to a rack-and- > > pinion focusing mechanism on an optical tube. > > > > Thanks, > > > > -- > ******************************************* > VISIT MY HOME PAGE: > <http://home.online.no/~eikarlse/index.htm> > LAST UPDATED: 23/08/2003 > ******************************************* > Regards > Eirik Karlsen |
|
|
Reply by ●January 5, 20052005-01-05
|
The software is WebPack ISE and version 6.3 is available at www.xilinx.com. It works for a bunch of chips from the smallest CPLDs up to the 4M gate Spartan 3. > I've been thinking seriously of the evaluation board that you > mentioned, along with the free software. There are some designs > where an FPGA is real nice to have. Unfortunately, I don't have > Mentor (and it's 10K price tag) at home. But am seriously > considering as you mentioned. > Sure! Go ahead and send it to: > > rich@s... I can't use that email address outside of Yahoo and I can't attach a file inside Yahoo. Send an email to my full address, for some strange reason it is not hidden. > > you have to develop your own BIOS but that can be quite simple and > > really involves following a well paved yellow brick road. > > Cool! Well, I think that I can still puzzle out the 8080 assembly > code, and I can whomp up an RS232 driver for the console no > problem. There are some demo stuff for PIC to Compact Flash, so > that might be an interesting option. I don't feel like doing the > floppy interface. Now, if I still have those 8 inch floppies > and drives (I know I have the drives). Well, I could get wordstar > up and running again! I did that... Actually, I used my CompuPro Z80 to send the files to the PC and then from the PC to the new system all using Kermit. Can you believe Kermit is still is use? I actually bought a new licensed copy from Columbia University. > > Might/would be fun to play with. I've got a Z80 with 32K of RAM > already wire wrapped up. Be nothing to do a uart for it and shoot, > with 32K EEPROM, I should have all sorts of room for a boot loader.... > > Yes, CP/M is a good little DOS. Small enough to get a handle on > what you needed to do and light enough to run on very small systems. > > Heck, I can throw another 32K of RAM in there (shadowed of course) > and have a "full blown" system. I think that it runs about $20 > for the Z80, clock and memory chips at today's prices, a tad bit > more with sockets. I suppose that I'll have to try doing double > sided boards at home. Well, it will be fun. In fact, I might > just blow the dust off the ADM3A terminal that I used to use for > my cp/m machine in the late 70's! That would be ironic. > > If you could also toss in some instructions/links to the additional > software, I would appreciate it. I did copy the cp/m 2.2 stuff > a while ago when they mentioned it being available on slashdot, but > did not persue it too far. > > I'm guessing that one uses the emulator to assemble the CPP, BDOS > and BIOS for the target machine, yielding a couple of binary files. > Are there utilities for putting them on media for boot up? It's > kind of the chicken and the egg sort of thing. Ah, that's the rub. I wrote the code to download a hex file and put it in a shadowed bit of ROM. It in turns downloads a hex file called Builder.hex which will then format the drives and request, download and write to track 0 the 3 files for CP/M. That particular bit of ROM is only executed if the configuration dipswitches are set to A5h, otherwise the coldstart loader is executed to bring in the entire CP/M system. That bit of ROM code has to be mangled into something that can be used with an FPGA configuration file because the bit pattern is set in BlockRAM when the FPGA is loaded. |
Reply by ●January 5, 20052005-01-05
|
How fast are you spinning the motor? Maybe you are running out of time... --- In , "cjl023" <cjl023@y...> wrote: > > Eirik, > > That's a good point. > > I'm driving the motor using a TEA3718. It drives a constant current > through the motor using switch mode current regulation. The power > and encoder channels all run through the same flat 6 conductor piece > of cable. This is just the way the motor is put together. It comes > off-the-shelf this way. > > Thanks for your help and counsel. I will look into isolating these > cables from one another and see if it helps. > > Take Care, > --- In , Eirik Karlsen <eikarlse@o...> wrote: > > Ok. > > You may well have noise in the system. Use screened wire for all > > feedback signals, screen to proc. gnd. > > Also try screening the motorwires. Motordrive signals (especially > PWM) > > are very noisy. > > > > cjl023 wrote: > > > > > > > > Eirik, > > > > > > I dynamically brake the DC motor by momentarily reversing the > > > voltage applied to it for 20mS. This stops the motor dead in its > > > tracks. > > > > > > I'm using a TEA3718 to control the motor, and always turn it at > the > > > slowest speed possible, when positioning it in the described > manner. > > > > > > It's just a small 9VDC motor with a gear box that then has a > shaft > > > that comes out both sides of the gear box. One of the shafts > > > connects to the encoder. The other shaft connects to a rack- and- > > > pinion focusing mechanism on an optical tube. > > > > > > Thanks, > > > > > > > -- > > ******************************************* > > VISIT MY HOME PAGE: > > <http://home.online.no/~eikarlse/index.htm> > > LAST UPDATED: 23/08/2003 > > ******************************************* > > Regards > > Eirik Karlsen |
|
|
