Re: Motion control and RELATIVE position problem

Scott Seidman wrote:

-snip-

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.

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.

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.

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.

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.

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.

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.

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
Wescott Design Services
http://www.wescottdesign.com
.

Relevant Pages

  • Re: Algorithms to generate permutations
    ... >>The position on algorithm design, ... > I claim that my government should not insist ... Would this have forced a US national competition? ...
    (sci.crypt)
  • Re: Implement ARM cores on a FPGA chip?
    ... directly using FPGA fabrics seems to be the only promising solution. ... Martin indicated that if your algorithm is amenable to breaking it ... to partition your design. ... processing elements are designed for a particular task so that it can ...
    (comp.arch.fpga)
  • Re: Encryption key changing the encryption logic.
    ... >>decides among various elementary crypto operations based on what it sees ... >>adversary knows which key bits select which algorithm and, in practice, N ... > or two rounds of a different block cipher. ... this design is covered under the 1-of-N discussion and your design is ...
    (sci.crypt)
  • Re: Test-Driven Development
    ... > Michael Mendelsohn wrote: ... The design is very similar to yours, which confirms a supposition I pose ... below, namely, that test design affects the algorithm design. ... > general-purpose algorithm generator, ...
    (comp.programming)
  • Re: Determining Plant Bandwidth
    ... Tim Wescott ... Wescott Design Services ... My objection to pole placement design is that you have to look at the plant model and, based on the plant model and lots of experience, guess at a set of target pole locations that will result in a robust closed-loop system. ...
    (sci.engr.control)