![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
valemike Guest
|
PIC with several INDEPENDENT PWMs (and CAN) |
Posted: Sun Mar 20, 2005 10:59 am |
|
|
I noticed most general purpose PICs with PWM have only 2 independent PWMs, i.e. CCP1 and CCP2. Are there any PICs with up to 4 independent PWMs, preferably with CAN? I know the correct answer is "RTFM", but from all my reading on the Microchip website, i've only found that the PIC18F4X31 has several independent PWMs; and i'd have to go to the DsPIC w/no CCS compiler to get independent PWMs + CAN.
Probably the first answer that comes to mind is to get a PIC with ECCP, but i'm already using such a PIC (18F448); however, i cannot get more than one independent PWM from the ECCP module.
-Mike |
|
![](templates/subSilver/images/spacer.gif) |
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Sun Mar 20, 2005 11:59 am |
|
|
Digikey's catalog is great when it comes to picking out a micro
http://dkc3.digikey.com/PDF/T051/0348.pdf
Last edited by Mark on Sun Mar 20, 2005 3:02 pm; edited 1 time in total |
|
![](templates/subSilver/images/spacer.gif) |
bluetooth
Joined: 08 Jan 2005 Posts: 74
|
|
Posted: Sun Mar 20, 2005 2:19 pm |
|
|
Mike:
I think your investigation was correct - the only way you're going to get CAN and all the PWM resources of the xx31 series on the same chip is by going to the dsPIC. You could consider an MCP2515 added to a 4431, but you have to be careful because the xx31's are code space limited. If it's just a CAN compatible PWM generator, this solution should work ok....
Microchip needs to put that power control module from the xx31's on more parts - it's really handy! |
|
![](templates/subSilver/images/spacer.gif) |
Guest
|
|
Posted: Tue Mar 22, 2005 4:41 pm |
|
|
bluetooth wrote: |
Microchip needs to put that power control module from the xx31's on more parts - it's really handy! |
You know what else they need to do? Is to put a "braking" mode in Full Bridge mode in the ECCP so that one can short the two bottom fets without going thru the grueling task of configuring them as i/o pins and bitbanging! ![Mad](images/smiles/icon_mad.gif) |
|
![](templates/subSilver/images/spacer.gif) |
bluetooth
Joined: 08 Jan 2005 Posts: 74
|
|
Posted: Tue Mar 22, 2005 6:26 pm |
|
|
Anonymous wrote: |
You know what else they need to do? Is to put a "braking" mode in Full Bridge mode in the ECCP so that one can short the two bottom fets without going thru the grueling task of configuring them as i/o pins and bitbanging! ![Mad](images/smiles/icon_mad.gif) |
Is it possible that they're worried about blowing up those transistors without some form of current limiting (i.e. braking resistor)? Ideally, they'd add the pins to connect the resistor as well! |
|
![](templates/subSilver/images/spacer.gif) |
valemike Guest
|
|
Posted: Wed Mar 23, 2005 6:52 am |
|
|
bluetooth wrote: |
Is it possible that they're worried about blowing up those transistors without some form of current limiting (i.e. braking resistor)? Ideally, they'd add the pins to connect the resistor as well! |
The only motor control experience i have is to program the fet firing, so i don't know everything about the hardware. I can tell you though that we are using the International Rectifier power modules that can take up to 600V and 10A. So if braking by turning on the bottom fet(s) can cause current spikes and potential damage, i guess i'm lucky that the part chosen is capable of all that current.
By the way, when i brake going in the Full Bridge Forward direction, i found that i can conveniently just change the ECCP mode to a single PWM (P1A) and just pulse that. As for the other bottom fet, we've got freewheeling diodes on all of them, so current can flow thru the other bottom fet. However, going the full bridge reverse direction and braking unfortunately does not have a single PWM mode, and that is why i'm stuck bitbanging that direction. Thus my bitbanged PWM in that case is a bit inconsistent, especially with encoder and timer interrupts interrupting me in the middle of my bitbanged duty cycle software time delays. |
|
![](templates/subSilver/images/spacer.gif) |
bluetooth
Joined: 08 Jan 2005 Posts: 74
|
|
Posted: Wed Mar 23, 2005 7:17 am |
|
|
Yeah, we're using some of those IR modules as well - they're bullet proof!
You have to be careful just shorting out motors to brake them - with a low enough shorting impedance, you can demagnetize the motor. The IR parts are nice because they'll shut off the drivers if the current gets out of hand (which, BTW, is REALLY handy for initial BLDC driver development!).
Most of our applications are closed position or velocity loops, so the braking action happens as part of the control loop anyway.
That pesky hardware - the only thing standing between us and "true" computing! ![Rolling Eyes](images/smiles/icon_rolleyes.gif) |
|
![](templates/subSilver/images/spacer.gif) |
valemike Guest
|
|
Posted: Wed Mar 23, 2005 7:28 am |
|
|
bluetooth wrote: |
Most of our applications are closed position or velocity loops, so the braking action happens as part of the control loop anyway.
|
So you use IRF's modules as well, huh? You're right, they're the best to work with. No need to worry about board layout with those modules. (Others, such as ST, are very sensitive to board layout, which means several blown drives and fireworks displays in the lab!! )
I've done PID for temperature control, with help from Embedded Systems Programming magazine's article "PID without a PhD". Haven't tried it for motors yet. I was wondering how you can put in BRAKING as part of your PID algorithm.
By the way, i'm using brushed DC permanent magnet motors. Some can be 24V, 48V, 90V, 120V rated.
Do you update your closed loop algorithm (i.e. PID) every, say, 100ms, for a motor? How does your PID algorithm know when to brake vs. when to simply decelerate? Perhaps, since our application can take several different motors, then i'll never have a truly tuned PID algorithm, and probably easier to just stay with non-closed loop control ![Mad](images/smiles/icon_mad.gif) |
|
![](templates/subSilver/images/spacer.gif) |
bluetooth
Joined: 08 Jan 2005 Posts: 74
|
|
Posted: Wed Mar 23, 2005 8:06 am |
|
|
Most of our our position loops run at 1 KHz, and motion happens when we change the command position vs. time (the motion profile). The servo loop's job is to drive that position error to zero (command pos - actual pos) - so if the motor starts to get ahead of where it should be, the control loop reduces, or even reverses, the drive to the motor in an attempt to drive the position error to zero. Thus, you get a "braking" action. The opposite happens if the motor is behind where it is "supposed" to be.
Are you trying to control motor speed? |
|
![](templates/subSilver/images/spacer.gif) |
valemike Guest
|
|
Posted: Wed Mar 23, 2005 8:21 am |
|
|
This is for a pedestrian automatic sliding door (supermarket, hotel, airport doors, etc.) controller.
I let the customer choose the speed he wants to OPEN the door via an LED display and keypad. Indirectly, he is choosing the PWM duty cycle. For heavier doors the motor moves slower, for lighter, it moves faster at the same PWM duty cycle.
There are UL standards though for closing - i.e. 12 inches per second is the max. It is up to the installer to choose the suitable PWM duty cycle for closing at 12 inches per second.
Thus i am not really controlling "speed", but rather i let the guy choose the duty cycle. However, it would be nice to be able to control the speed. So the guy can simply choose on the keypad, "How many inches per second should the motor move".
I also need to be able to make sure a person isn't crushed, thus i need to watch the motor current and/or the encoder rate, and if i see a considerable slowdown in encoder rate, i have to stop the motor. Thus closed loop speed control will end up crushing an obstruction in the path.
~~~~~~~~~~~~~~~~~~~~~~~~~
Hey, since you are into H-bridges motor control --- i have a question. When reading the motor current, am I supposed to read it only when the PWM is "on"? Looks like i will need to synchronize PWM "on" with taking an A/D sample. oh well. |
|
![](templates/subSilver/images/spacer.gif) |
bluetooth
Joined: 08 Jan 2005 Posts: 74
|
|
Posted: Wed Mar 23, 2005 8:31 am |
|
|
Sounds like a classic closed loop application with limits. You are on the right track - you can detect problems by noting velocity errors or excess current. Seems like a velocity loop would work here.
In terms of the current measurement, we run the current sense in to a hardware integrator (just an RC) to get the average current. We then read this periodically and compare it to limits. Time constant set to be much longer than the PWM freq... |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|