Hi, I'm using a PID controller software made by Microchip. It work pretty well. The PIC receive command from a host computer by serial link. But lately I had some problem and figure out why. I can only send relative position.
So for exemple, if I'm in position 1000 (encoder countd) and want to go to 2500, I issue a "getPosition" command and substract it from the desired position, so relPos = desiredPositon - getPosition(), so it would be 2500 - 1000 = 1500. So the controller will try to move of 1500 counts. Then my final position will be 2500. But imagine the motor is oscillating (+/- 100 count) (This will be a little bit hard to explain). At the moment a send a 'getPosition' command, I read 1100, so my relative motion will be of 2500-1100 = 1400. Now at the moment I send the command of 1400 counts, at the EXACT moment the controller receive it, my current position is 900, the controller will move of
1400 counts from 900 counts, so my final position will be 900+1400 =
2300.
Did you had this problem with a relative position controller? How you solve it? I think of one solution is to check my self (with the host computer) and resend a command if I'm not in the desired absolute position.
Find an absolute position command and use it. If you can only find an absolute position command in an entirely different set of software then chuck what you have now and go with the new stuff.
This isn't a motion control problem per se: the problem is that you want absolute positions, your start position is moving and you can only issue relative commands. Since you cannot issue the command at the same moment that the position is sampled you cannot guarantee that the controller's final position will be what you want.
Tim Wescott wrote in news: snipped-for-privacy@corp.supernews.com:
I'm afraid I'm missing something-- assuming a good reference point, there's no difference between controlling a system with an absolute vs a relative encoder, so long as no counts are missed.
You don't send a servo system the number of counts it needs to travel-- you send it the desired position, and let the controller keep track of the error, and move it in the right direction until the error is zero (or near it).
The start position of the relative encoder, unless somehow set otherwise, is the position when the thing was turned on (at least if properly initialized). The real problem here is the large delay between when the position is sampled and when the motion command is modified--and its probably responsible for the oscillation. If you can't deal with this delay, you won't be able to control even an absolute system.
This seems to be the real problem! A PID controller that can only recieve relative commands isn't worth the silicon its laid out on.
I'm having trouble believing that the Microchip software behaves in this way. A PID system receives the command as its input, not the error. If you're at 1000, and want to go to 2500, you send the command 2500, not the difference of 1500. You do it this way regardless of whether you're using an absolute or relative encoder. With the absolute encoder, you have the luxury of being able to miss counts, but that shouldn't be a problem anyway. You can use the PIC 18F2331, or 18F4331, which has quadrature inputs, and never miss a count. Or you can use any PIC you feel like, and use an HCTL2020 to keep your count. Either way, you'll never miss any counts. The OP will need to write the PIC program, but you must be programming the PIC in any case. If the program can't be modified, the same delay would kill you with an absolute encoder as well.
FWIW, Microchip doesn't make PID controllers, but they might have published code or an application note the OP might be using. Most of the code I've seen from Microchip (which all use absolute commands, BTW) seems to make use of the counters to count quadrature. I've had problems using this approach (because of a 1024 count encoder and a
196:1 gear down to boot), and seem to have missed counts. I've never figured out why (and spent some time trying), but I suspect it was noise, or too much overhead when polling the counts. The encoder inputs on the 18Fx331 have noise rejection that's software programmable, and no overhead when polling the register for the count, and the HCTL2020 has noise rejection built in, and maintains the correct count even when its output is latched for reading. The controllers I've built this way have been fairly bullet proof.
The key is to give the PIC your command asynchronously, use a timer interrupt to poll the current position, calculate your error, and modify the output to the motor accordingly. You should be able to do this at more than 500 Hz with a 20MHz clock.
If the OP is willing to spend about $150, there are a slew of pretty good controllers out there, even pic-based. I haven't used them, but
That's why I was suggesting that if he had something that did not work that way he should chuck the software.
-snip-
My point.
-snip-
I haven't looked at any of the Microchip app notes that closely. I'm generally suspicious about code from app notes unless the company is _really_ trustworthy -- IOW if they're Motorola. I don't even know if that still holds now that they've spun off FreeScale. I suspect the OP is missing something in the available commands.
I guess I am asking more than answering ... I'm not very familiar with the how this whole setup works, but if the incoming signal is "oscillating" at the same frequency of the sampling, shouldn't he just increase his sampling rate according to Nyquist's sampling theory and he should be ok?
He didn't say that it was oscillating at the sampling rate, he just said it was oscillating -- and yes, that's a problem but it's a separate problem and may not even be with his controller (his application could have a large disturbance input, for example, which would cause the motor to "oscillate" in some folks' terminology).
If the oscillation were from tuning, then obviously that should be addressed.
I use the code in Microchip applicatio note AN718 title "Brush-DC Servomotor Implementation using PIC17C756A". Look at page 9, the last paragraphe it's said "In Position Mode, a 16-bit relative movement distance is entered as encoder counts divided by 256.". Look again at page 12, to time you will see "relative position". Just do a search with the word "relative". So tell me where did you see code from microchip that use absolute position? Application note AN696 and AN 532 use relative position too (again make a "seach" on the pdf file). So I CAN'T send a command of 2500 if I'm in position 1000 to go at 2500.
I use the code in Microchip application note AN718 title "Brush-DC Servomotor Implementation using PIC17C756A". Look at page 9, the last paragraph it's said "In Position Mode, a 16-bit relative movement distance is entered as encoder counts divided by 256.". Look again at page 12, two time you will see "relative position". Just do a search with the word "relative". So tell me where did you see code from microchip that use absolute position? Application note AN696 and AN 532 use relative position too (again make a "seach" on the pdf file). So I CAN'T send a command of 2500 if I'm in position 1000 to go at 2500.
louis snipped-for-privacy@hotmail.com wrote in news:1123516102.898386.265330 @g49g2000cwa.googlegroups.com:
Try AN937, for an example-- its listed under PID in the mechatronics category. The whole routine takes under 100 us, so your lags should be non existent in a real time scale.
Frankly, relative control the way this note describes it is a silly thing for a dynamic system-- you need to get the current position via RS232, caculate a relative command based on your absolute needs, and send it over RS232. This will cause huge delays. Think about sending the absolute endpoint via RS232-- when received, the embedded controller can then go calculate the error based on where your motor is NOW. Simply by sending an absolute endpoint, you can replace two relatively long UART delays (plus whatever delay is added by your calculation and typing) with one subtraction to calculate your absolute error (about 4 clock ticks!!), and this should end your problem.
Take the applications notes for what they are-- thumbnail sketches on how to get a job done--not necessarily the best way to do it, and not even guaranteed to work. Read ALL the relevant notes, and take the best bits and pieces from each. You should be able to wade through the software and figure out how to provide the algorithm with an absolute command instead of a relative command. I think Tim Wescott has published a PID algorithm in the past that is relatively easy to port to PICs, as well.
I know it seems frustrating, but once you start playing with something as deeply embedded as this, you should jump in with both feet. It's tough to make things work unless you understand the task at a fairly fundamental and algorithmic level, and can make the system do exactly what you need it to do. If you're not willing to get comfortable at this level, then each task you take on has a real possibility of turning into a can of worms. You invest enough time in it to realize its a hair over your head and then pick another tack, so it can be a huge resource waster if you're not careful. Even if you have the skills, if you can find a reasonable off-the-shelf solution, its often cheaper in the long run than rolling your own embedded system.
Otherwise, you might as well go with the $150 controller from jrkerr--it really seems to be quite a deal. If you're a student, or not under any time pressure, keep hammering away at your own custom-tailored embedded solution--it's good for your soul, and will make you MUCH MORE VALUABLE.
FWIW, I ended up building a PID controller because I needed to drive it with an analog signal, and get the position output with a D/A and the reasonable commercial systems I could find used a 10-bit A/D, which wasn't high enough resolution for my needs, and didn't provide D/A outputs.
As a last note, I recommend avoiding the 17C line of PIC entirely. It's userbase is extremely limited. Stick with "F" chips--you have a lot more flexibility while debugging code. Move to the 18F line (if you can afford the compiler), or stick to the 16F line, and you're more likely to get support from a big userbase. This doesn't seem important, until you get a note from a user that points out a mistake in the documentation for the PIC you're trying to use, or a small hardware bug with a workaround. Input like that can keep you from tearing out your hair, and a large user base is the only way to get it.
It would help if you described the nature of the oscillation in readings (presumably from a quadrature encoder).
Is it a maximum of +/- 100 counts or does it always get that wild.
What is happening to the shaft of the motor while these counts are oscillating.
Is the absolute position with reference to anything at all or is it just arbitrary.
With the answers to the above three questions we would all have a bit more leverage on your problem and might be able to provide a more specific and concrete solution.
Easy to port if you know how to make a PIC do the math. If you just take the code as written it will be a couple of orders of magnitude slower than if you use fixed-point arithmetic with hand-optimized multiplies in assembly.
Ask for a sample snippet of code before you proceed, though. I'm working with one of those off-the-shelf solutions for a PIC and it could be used as an example of unmaintainable code. Partially this is because it's heavily optimized, and the PIC is not amenable to fast, well-structured C code, but partially it's because (in my humble opinion) the guy writing the code didn't really pay attention to maintainability.
Yes it will. When I interview people I ask questions and listen to answers to find out what they've actually done, and at what level. To earn top points from me folks need to demonstrate that they can understand all levels of a development effort, and that they know the level that they're being hired for intimately.
As a last note _I_ recommend avoiding PICs entirely. Atmel makes the AVR line of microprocessors that has all the same features of the PIC, plus an instruction set that was designed from the get-go with input from a compiler group. As a result you have much less temptation to write terribly structured code "because it'll be more efficient".
I would apply the same advice to the 8051 but (alas) it is just too damn popular.
And lest I start a flame war: These are just my opinions, and I may design a PIC (or an 8051) into a product tomorrow (particularly if the client pays by the hour :). There are huge numbers of good products that are based around PICs and 8051s, so even though _I_ think they should all be used as doorstops shouldn't keep _you_ from making good stuff with them.
Tim Wescott wrote in news:11ff8hph9rtgtd8 @corp.supernews.com:
I've always wondered why you used floats in that PID code, and I've chalked it up to illustrative purposes. It might not run fast as written, but its easy to follow. Is there a link to that, BTW?
Understood. If I was doing more embedded work for a living, I'd cast a much larger net with much finer holes before I settled on a family. That said, I haven't had much trouble with the PIC. I think the CCS compiler takes much of the pain away, handling paging and so forth, so long as you don't need to concern yourself with how fast the program runs and what the assembler looks like. Certainly, the c-code is easier to follow than what I see from my friends using Hi-Tech.
The 18F series has a better instruction set than you might be used to, if you've stuck with the 16f so far. It also has nifty features like hardware 8x8 multiplies, and good support for motor control (e.g., direct quadrature input--huge deal for when your count is tearing along real fast--3 PWMs and their complements with a deadband for brushless control). I'm anxious to see how ccs supports the dsPIC (which they've been promising for 6 months or more). Now THAT looks appealing-- dsp for a few dollars!
I learned how to code a uP on a 68030, using a firmware board with a keyboard tied directly into it--no assembler, looking up the hex code for each and every command and argument. If you needed to edit a line on the firmware, you'd hope to hell that the replacement command took up the same or less bytes than what it was replacing, so you wouldn't have to reenter your entire code from that point on (You'd learn pretty fast to throw in liberal NOPs between statements!). By that standard, there isn't a development environment around that isn't tons better than that, so I guess I'm easy to please.
Sounds like the AVR line is worth a look-see, so long as the compiler doesn't cost an arm and a leg. Which of the more reasonably priced compilers do you recommend for the AVR?
Have you tried Cypress PSoC? I've been thinking about picking up a dev kit just to see what's up. I try to go with products with a large base of development tools, for obvious reasons, but when you look at all the beautiful analog conditioning tools right on the chip, it has some appeal ("My board will be smaller!!"). Then you think about how lovely the analog stuff you just place on your PCB now actually works, and how little design time goes into it, that you wonder if the PSoC path is worth it.
I used floats purely for illustrative purposes (in fact as originally published I hadn't even compiled the code -- I learned a lesson there). In practice I wouldn't hesitate to use floats _if_ I had plenty of excess processor power, but on most processors floating point is way slower than fixed-point arithmetic. Since others have covered embedded fixed-point math I haven't tried to address it.
A link to the article, or to just the code? The article's on the Embedded.com website (they own the rights), but I've got a pointer to it on my website
formatting link
They used to have the code available as a stand-alone download, I don't know if they still do.
I've heard that, and will check it the next time I'm involved in selecting a processor. Usually my clients come to me after the processor choice is fixed in stone, so it's been a while since I've had the opportunity.
In fact I've got a DSPic sitting on a board design that I work on when things are slow. It'll probably never actually get built 'cause I'm pretty busy these days, but it's sure intriguing. I actually selected it more for the 2.7-5.5V VCC range than price -- going straight from batteries to the chip was _very_ appealing in this case.
By the time the PIC became popular I had moved to a company that built small-volume high-performance equipment, and the philosophy was to save software engineering hours by way over specifying the hardware. We did have one project where we actually selected the AVR (over the PIC) and got as far as doing some sample code with it before the project was canceled, but that's the closest I've come.
When we selected the AVR it was on the bleeding edge and the only compiler available was the IAR. Since then a bunch of them have popped up, none of which I have experience with.
formatting link
used to list a bunch of tools for the AVR, but the site has gotten _much_ slicker since the last time that I looked so I don't know how to get around it easily any more.
I've seen it. I've had the dubious privilege of being dragged through the first few attempts at analog programmable hardware -- they were always so bad that we found the flaws before we even got samples. It's made me very cynical, but if the application comes up that might use it...
PolyTech Forum website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.