Pic BDC Servo

[bsharp]

Yea I did not like the idea of using an opamp ether . I am going to build an HBridge using high power mosfets with optodrivers for the power stage. But the source gives me something to start with anyway. Ill take a look at that variable tomorrow and see if I can figure it out .

[bsharp]

Well got the dsPIC30's in.
First thing was to get them hooked up so I could Program them.
I used this Idea for a simple serial programmer.
http://www.piclist.com/techref/picli...apic/COM84.htm
It seems to work well but some times it fails to write correctly.
So I will most likely add an amp to the MCLR supply to up the volts a little.
The next thing was programmer software.
http://www.qsl.net/dl4yhf/winpicpr.html
As it will work with most dsPIC's.
I am going to start working on the encoder interface and control IO.
I will post some pics when I get a chance.

[michael_giesbre]

I have some experience using the DSPIC 30F4011 for motion control (using PWM and the Quadrature Interface) so I've go that part pretty much figured out (mostly) but I'm having a little difficulty fdiguring out how to collect the step and direction signals to create the desired position. Maybe we could combine our efforts on this project? I'm using the DSPIC 30F4011, programming in basic with an in circuit programmer from Mikroe.

[michael_giesbre]

Ok so I had the whole system setup last night. As a test to get the PWM and Quadrature systems working correctly I have Setup my motor/encoder combo like an RC servo (it just tries to maintain a position) When I deflect the encoder the motor turns on to correct, with the duty cycle being calculated through the PID function. The problem that I am having with it as is, is that when I deflect the encoder in one direction, the system works properly, and the speed of the motor is somewhat proportional to the error (as I increase the error the speed increases). When I deflect the encoder in the other direction, the proportionality seems to be opposite, a small defelection gets a very fast speed, and as I increase the deflection, the speed decreases.

I also had a thought about using an external interrupt to count input pulses, basically on an interupt, the controller goes into an interupt routine that checks the direction (ie high or low) and then increments or decrements a counter variable accordingly. Even at Mach's maximum frequency (45 kHz right?) this should leave lots of cycle time in between input pulses to implement the rest of the control

Any thoughts?

-Mike

[michael_giesbre]

Tried out using interrupts for counting pulses, and also figured out the problem with the PWM. Now the system reacts correctly to the errors, and will move as needed to correct for each pulse that is input into the controller.

yesterday I messed up one of my Mosfets. I replaced them all today (just to make sure) and had a bit of an interesting problem with them........

When I applied +5V to one side of the bridge everything worked fine and the motor came on.


When I applied +5V to the other side of the bridge, the high side mosfet on that side of the bridge started smoking (right away) so I quickly removed the power. Then the mosfet started to smoke more. Then alot. Then the flames......

Anyway everything but the hbridge is ok, but it is toast. As is the breadboard it was on. and everything else on the breadboard.

So that is the end of experimenting with high power motor control on my desk in my room.....

Anyway once I have the code perfected I'll post it, as well as the schematics for the circuit

[Horsedorf]

Ohhhh. OUCH.. I HATE it when that happens. Though it's not as bad as powering up with your face over the circuit board and having bits of plastic suddenly embedded in your face. Been there, done that.

[michael_giesbre]

Ive done that too!!!! Im beginning to think that electronics and I don't agree....

[rdpzycho]

same here..I hate it when MOSFETs burn..

how do you upgrade the position variable? I tried this before but using Step/Dir makes the motor move unlike a servo, it overshoots and hunts..I ended up trying to make a program that reads G and M codes that could directly communicate with my drivers so it upgrades the position variable as a whole..but it seems like I ended with a bit harder project because I need to make room for kinematics/interpolation..overall, the project is postponed until I have enough time to play with it again..

[bsharp]

Sorry I haven't had the time to devote to this project lately. I did get A PICKIT2 to speed up programming the chips. I currently have the DSpic, voltage reg's and encoder input optos on a perf board. All I need to do is setup a serial interface to set the PID parameters and I can start testing the output of the DSpic. I have played with the code from the dspic servo project and "think" I have it modified for step and direction inputs. I still need to design and build the output stage. Hopefully I can get some of my other projects done over the holiday and I can devote more time to this one.

[rdpzycho]

btw, on my project I used 3 MSP430's to accomplish different tasks and let them pass data through a bus. I never looked at how the data is transferred from my step/direction controller to the PID one.

I just never had a better controller at that time so I resorted to using 3 closely powered ones. (one processes quadrature signals, one for PID, one for step/direction counts; I just graduated college when I started the project and had not enough money to buy development boards for more powerful controllers).

never had time for this project for around 2 years now.

[michael_giesbre]

Originally Posted by rdpzycho same here..I hate it when MOSFETs burn.. how do you upgrade the position variable? I tried this before but using Step/Dir makes the motor move unlike a servo, it overshoots and hunts..I ended up trying to make a program that reads G and M codes that could directly communicate with my drivers so it upgrades the position variable as a whole..but it seems like I ended with a bit harder project because I need to make room for kinematics/interpolation..overall, the project is postponed until I have enough time to play with it again..

Basically I setup an interupt routine that is triggered on every step pulse coming into the controller. The routine checks the state of the direction input (high/low) and increments or decrements a variable accordingly.

The quadrature counter uses the poscnt register to count encoder pulses.

They rest of the program on the chip just compares the value of the step variable and the poscnt register to determine position error, then applies the PID algorithm to correct for the error. I'm still working on getting the PID algorithm right, but using a simple Proportional control actually works pretty well as long as the gain is not to high.

The overshooting and hunting that you were seeing was probably caused by poor gain settings for your PID algorithm. If using only proportional control the controller will tend to do this unless the gain is set quite low.

The other thing that you want to do is allow a little bit of a "fudge factor" on the position error (I'm using 2048 line (8192 ppr) encoders so If allow a window around the desired position of 50-100 pulses it results in a very very tiny linear position error of the system, but makes the controller alot more stable. (Basically once the controller gets the motor to within the "fudge range - about +/-50 counts" it turns off the motor power, and (hopefully) the motor will come to a stop within the "fudge range" and so the controller will call it close enough - as long as the motor is not at very high speed this actually works quite well, and only proportioanl control is needed. (with a 2048 line encoder and a fudge range of +/-50 counts, on a 12 TPI lead results in a MAXIMUM linear error of 0.0005" (that is if the error is +/-50, but because of the slow down of the motor, this usually ends up being quite a bit closer)

It is important to note that this only works with slower motor speeds, a faster motor speed will require a much larger fudge range, and therefore will result in much lower accuracy (unless some overshoot and return is allowed)
The I & D terms of the PID will help to allow faster motor speeds with high accuracy.



Mike

[rdpzycho]

thanks.

I also thought it might be the gains, but no longer played much with them. it can follow a whole distance command but cannot keep up good with stepping sequence. linear interpolation of two axis results in a wobbly line but at some point the line goes straight. I only got 500 ppr one.