This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Question about adding precision position control to FOC-style algorithms

I didn't see anything like this posted around, but I 'm kind of surprised it wasn't. There's quite a lot of commercial activity nowadays on the topic of using motors for axis control in applications like CNC and 3D printing (additive manufacturing) applications. These usually start with TB6600-style stepper motor drivers for the smaller, lower current steppers, and at the higher currents these appear to have frequently evolved into applications for Piccolo-style DSPs usually driving discrete power MOSFET bridges; there are even models which accept simple quadrature inputs in a "quasi-closed-loop" fashion (just to make certain each step actually was executed and didn't get overwhelmed by a requirement for excessive torque which typically results in errors that are a multiple of 4 steps which can then be re-executed). Now at the very next level there are controls which are supposed to be for brushed DC motors, now some of them CLAIM to be "closed-loop" systems but frankly most of them don't actually have an operational "position mode" because we knew forty years ago that to do a decent position mode you really had to have analog feedback like you'd get from a sin-cos incremental encoder (like for example the Heidenhain ERN 1387 which has been designed into some elevator control systems) but these crude devices use garden-variety digital-only encoders which for this application are complete rubbish. I have no idea why such an obvious scheme seems to have eluded that market so far but what I believe most designers would really like to see is a controller that could be used with BLDC motors. Unfortunately with BLDCs there is so much emphasis on low-cost "sensorless" velocity-only operation (and that's fine and has its place) that when an accurate position sensor IS available there's just no way to integrate it into the system, whether or not such an encoder is "absolute" (that would increase cost markedly and in my opinion unnecessarily) and would therefore be used to somehow assist commutation. There are also a wide variety of simple chip-level BLDC controls that are also velocity-only, and essentially ALL of them require the ability to move the armature "randomly" at startup, which in a precision positoin application makes these idiosyncrasies intolerable! Could someone at least provide some clue as to what a block diagram of what a BLDC FOC controller modified for precision position appli9cation would look like, or is there an alternate to FOC for this type of application that doesn't drive up the cost too much, and some description of how it might work or the algebra behind it?

  • When you have a high precision position encoder, I don't think there would be any "random" movement at start up because the voltage is applied on the basis of the current position of the rotor. Since you mentioned a BLDC motor, the block diagram should pretty much resemble that of a DC motor, with position encoder and inverter acting as electronic commutator in the inner most loop.
  • I don't think you thoroughly understood the issue. The type of high-resolution encoder normally used for position loops is only an incremental encoder for cost reasons, you generally can't commutate on that because of ambiguity at startup. (A low-latency absolute position encoder nowadays runs at cost about $700!) When I talked about "random" movement with a sensorless chip I mean take the example of say an Allegro A4963, it's a sensorless BLDC controller, It's primarily intended to do velocity control and commutation, it has no provision for position control and at startup it has NO idea where the armature is positioned so it just "guesses" and if rotation starts in the wrong direction it just fixes it when it detects the problem. I'm not an expert on FOC but my understanding is part of the concept is to sense the position of the magnetic field in order to maximize torque, and you'd certainly like to do that in a positioner as well. It would be really useful if a BLDC controller were available (whether thoroughly integrated all into a chip, or almost but needing external power device bridges, or as an entire PCB) that had all this capability because the CNC/3DP market isn't exactly tiny! It "kind of seems" to me like the "on-station" position term needs to be added into the part of the algorithm where it could contribute to rotating the torque vector (because that's what you'r trying to do, is bias the position to what the sensor says is the real neutral position) but I'm not completely clear where in the FOC block diagram that might belong. (There will also need to be a substantial and carefully adjusted amount of "lead" provided in the position loop because you're sensing position but phase current controls acceleration so therefore you have a second-order system and of course that's only conditionally stable without compensation.) I hope someone here gets all that...!
  • There are high frequency injection methods used to identify the shaft position at zero speed and to run it at low speeds and transition to the regular one at higher speeds. But I am not sure if these could give the kind of precision needed as it is dependent on the algorithm and the quality of feedback sensors and circuits. Currently, TI's C2000 devices are used by customers in such sensorless applications. We don't have a supporting software for that right now though.

    I will leave it for others to answer if they have a better one.
  • The kind of position precision necessary for a usable 3D printer in the X and Y axis is on the order of 1.5 to 15 microns. Now that of course is specified on a linear scale but this is over at least many tens of inches of travel, I think you get the idea, it has to be fairly repeatable as well so clearly a position encoder is absolutely essential.
  • So with all the expertise on this forum, and with all the "context" I've been trying to provide, like doing position control with a brush-type motor and incremental encoder is "a piece of cake" (unless you screw it up like the market apparently did) there's apparently nobody here who can tell me whether I ought to start a position control BLDC strategy with incremental encoder based on FOC or reject it for some other strategy, and all you seem to understand is "if I want to commutate I need an absolute encoder that divides in sixths"? I'm sorry, where is my inquiry getting lost here?
  • You may need a mix of high frequency injection based initial position detection followed by working with incremental encoders. In theory it is possible. If you are looking for such a solution from us, we dont have it available.
  • I think I'll keep this up for awhile, I have a similar question on other organizations' forums. There clearly are "available strategies" for getting this done, they are available commercially but only as part of a larger system and the cost and complexity of their approach may not be practical for my needs. Look I have no intention of "trying to steal somebody's IP" but at SOME point this (BLDC with dual-mode control) will probably evolve into the favored approach in the market I'm trying to address, and since someone else has clearly already brought it to market it's by no means certain that my question cannot be answered in a reasonable way, besides I don't feel comfortable walking away from asking so early simply because one vendor (albeit a major supplier of PMIC motor drivers and similar devices) doesn't have an answer readily available.
  • Jeffery,

    Is there a question about a specific TI device we can help you with?

    Regards,

    -Adam
  • Not really, I was mostly posting here because Mr. Enzo Trupia said this was the proper place to direct my query. And it's fine, I have gotten some help, in the long run I could envision an application running on something like a Piccolo MCU with an appropriate supporting hardware design implementing some to-be-determined block diagram and algorithm, but for right now I'm a long way from addressing anything like that, I'm pretty sure that would be a different query at a different time.

  • Jeffery,

    If there are no further device questions, I will close this thread. Please feel free to post again at any time for device help or queries.

    Regards,

    -Adam