PIC with several INDEPENDENT PWMs (and CAN)

valemike · Guest

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 Crying or Very sad

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

Mark · Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA

Digikey's catalog is great when it comes to picking out a micro

http://dkc3.digikey.com/PDF/T051/0348.pdf

bluetooth · Joined: 08 Jan 2005 Posts: 74

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!

Guest · Posted: Tue Mar 22, 2005 4:41 pm

bluetooth · Joined: 08 Jan 2005 Posts: 74

valemike · Guest

bluetooth · Joined: 08 Jan 2005 Posts: 74

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

valemike · Guest

bluetooth · Joined: 08 Jan 2005 Posts: 74

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?

valemike · Guest

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.

bluetooth · Joined: 08 Jan 2005 Posts: 74

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...