Do you think NI can fix my PLL?

Hi:

I'm attempting to build another motor PLL system and running into some difficulties stabilizing the loop. Since there is a lot of work to do, I have considered contracting out the PLL design to a well known control expert outside of my company, so I can focus on building other subsystems of the project.

Basically, the PLL is to lock a 136mmx2.54mm Al wheel to a 400Hz reference (24kRPM, 1 pulse/rev position sensor). Must be 2nd order PLL yielding zero phase error with constant frequency input. Wheel to be driven directly by a Maxon 200W brushless DC motor with an Advanced Motion Controls B15A8 PWM servo driver running in open loop mode. I have found that the open-loop mode of the motor drive results in not very linear DC transfer of ref. voltage in to motor phase voltage out, as well as not yielding a very linear dynamic response as well (rise time != fall time, but only by about 10-20%).

I have suspected that this may be the root of why the PLL behaves quite a bit less stable than my modeling predicts.

A co-worker involved in the project has contacted National Instruments, and they will come in next week to tell us "what we need". I have serious doubts that NI solutions will either be appropriate from a design perspective, nor able to achieve results quicker/less costly than if I get a control expert on the task.

I suspect from what I've heard my co-worker say (he is a LabView programmer primarily) that what NI has to offer which applies to PLL implementations is a LabVIEW-FPGA platform. This would implement digital filtering of the sort needed to stabilize the loop. Of course, then also some digital IO would be needed to accept the reference and wheel position sensor signals, and D/A output to drive the motor power drive.

What is the view of "the SED community" on the appropriateness and likelyhood of success with this approach?

My assertion has been that PLL stabilization is not something that can be done the way most controls are handled around here (usually PID) where you can use heuristic algorithms to getting it to work). Rather a PLL must be computed via classical analysis and servo loop design methods, ie, do the math.

Since the LabVIEW guy has no such experience the only possible way this could work using the NI approach is if:

  1. NI has PLL tuning algorithms that can "autotune" successfully.
  2. OR NI will also provide us with contracted design assistance to have one of their experts tune and set up the digital filtering LabVIEW code.
  3. AND I am wrong about the need for analysis to solve this PLL's loop stabilization requirements.
  4. AND I am wrong about the non-linearities being the root of difficulties. Although, a digital platform might actually help in this regard if some sort of linearizing function must be applied. I suspect however, that this would be better solved by a simpler minor-loop synthesis approach. Ie, run the motor in speed servo mode using the drive and a speed feedback sensor (which should then be highly linear), and build the PLL around that.

What do you think?

I am quite opposed to this situation of employing NI, but need to keep an open mind. But from an engineering perspective, I think it is absurd even if it ultimately works to employ vastly complecx FPGAs and ultra high-level programming software, DAQ systems etc. to do the job of something that should be doable with a couple op-amps and a handful of resistors and capacitors.

Thanks for input.

--
Good day!

________________________________________
 Click to see the full signature
Reply to
Chris Carlen
Loading thread data ...

~~ snip ~~

I have no idea about what NI can do for you, but I notice you have 2 lots of

90' phase shift within the PLL loop so the maths is not like an ordinary electronic PLL, the conversion of rpm to phase difference unavoidably shifts 90', the mass of the flywheel also provides 90' phase shift - above a certain frequency determined by mass of the flywheel and the series resistance of the motor etc. this makes for a second order loop already but with no polo/zero compensation providing loop stability. I dont know what you have put in your model or if you have a loop filter as well, but it should be able to model it quite well even in a circuit simulator converting the mass of the flywheel to an electronice equivalent.

To get it to work you would need to make sure the open loop PLL gain is 90' at and around unity gain, this could well mean a very much lower loop gain.

Idealy the motor would have speed feedback to remove the phase shift from the flywheel, isnt the servo loop capable of doing this or is there a reason why it cant be used ?

Another option is to use a negative impedance motor driver wich compensates for the voltage drop acros the motor resistance thereby minimising the lag cuased by the flywheel (will then be slew rate limited).

I have done washing machine motor speed feedback controllers and many vco type PLL, but not motor phase control, what your doing sounds far more interesting than washing machines .... zzzzz

Colin =^.^=

Reply to
colin

"Doing the math" is great if you've got a precise model of the behavior of the system at each VCO/Control voltage.

Over small changes in load/frequency you probably only need two or three numbers to characterize the system over the small linear regime and you can "do the math" classically.

But when the system (in your case, not just electronic but electromechanical) is not truly linear but may be nonlinear over typical range of operation, and ESPECIALLY if you've got noise into your phase detector, then the classical math is no longer so easy.

The classical PLL math is still relevant to understanding the system and explaining why it's screwed up at certain regimes.

It is not necessary to do all the classical PLL math to come up with a working PLL. You'd be surprised at how many were done by seat-of-the-pants hey-lets-change-parts-until-it-works methods :-).

One thing that going digital allows is easy variablee tuning of filters (in the case of a PLL usually low-pass filter) to the averaging/windowing parameter that is relevant.

Tim.

Reply to
Tim Shoppa

Hello Chris,

In that case you might want to give Tim Wescott a ring:

formatting link

He know this kind of stuff quite well.

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Yes, I have modeled the motor as an electronic equivalent circuit, and set up loop compensation to provide >45 deg phase margin at unity, also

-6dB/oct slope through unity. On PM DC motors it worked very well, but with the brushless not so well. The indication that something is screwey is that when I made a quick adjsutment which improved phase margin at the expense of gain in the simulation, the actual PLL behaved worse, not better.

The motor drive is capable of speed servo operation but needs an analog speed signal. The only way to get this is by F-to-V conversion from an encoder, since no analog tachs are available for these motors. This is an open possiblity, and I expect should improve things. But then it would be impossible to get PLL BW to be more than a fraction of the servo BW. This is probably Ok though since it only runs at constant speed.

I'm considering going into the washing machine controls business after this, actually. I need some relief from complicated stuff.

--
Good day!

________________________________________
 Click to see the full signature
Reply to
Chris Carlen

I have found this to be possible with normal VCO PLLs, but motors present extra difficulties due to the need for an extra lead network. Because of this I have found myself only making things worse when using the "changing parts" method with motors. Then when I sit down and do the math and get it to look right on the AC analysis in SPICE, the real thing works just as advertized. Just having some gotchas with this

3-phase brushless DC thingamabob.

Yes, that is true.

Thanks for the input.

--
Good day!

________________________________________
 Click to see the full signature
Reply to
Chris Carlen

Yes,

"well known control expert" == Tim Wescott

--
Good day!

________________________________________
 Click to see the full signature
Reply to
Chris Carlen

This is a critical portion that you need to know inside and out. If you outsource, you will be constantly calling the guy whenever something goes wrong or doesn't work quite right. What kind of problems are you encountering? If the loop is wildly unstable, it obviously needs to be fixed. If you are asking for extremely tight control, i.e. picoseconds of phase error control in milliseconds of rotational period, maybe the requirements are too tight and need to be relaxed.

Small errors like this should have little effect. In a normal loop, changes in the response go as the square root of gain. For example, you can run a varactor pll from one end of the range to the other with satisfactory loop response even though the vco gain changes quite a bit.

Putting Windows software in the feedback loop is a recipie for disaster. Any consultant that recommends relying on Windows has no concept of system reliability and should be shot without benefit of blindfold.

You are absolutely correct. Any other seat-of-the-pants approach will not work. I've tried. You cannot possibly arrive at the proper loop components by guessing.

After doing the math and simulations and getting the loop operating correctly, you can trim the values to optimize the response at a desired operating point. But not before.

Unlikely.

Highly recommend do not rely on Windows software to close the loop.

This seems to be the root of the problem. Instinct tells me there is something being overlooked. PLL motor speed control is not that difficult.

Extreme linearity is not needed. You can get the loop operating fairly well, then trim to optimize the response.

Follow your instincts. You are correct.

Regards,

Mike Monett

Reply to
Mike Monett

Maybe the difference is that the brushless type doesnt like being reverse driven so the time constant of the motor/flywheel is variable depending much more on load when it is slowing down.

speed.

Well you already have an encoder albeit 1ppr, plus the frequency of the solid state commutation must be available somehow. F to V is easy todo. if only you could limit the frequency of commutation directly, say with a voltage controlled monostable trigered from one commutation pulse wich prohibited the next comutation pulse until it had timed out.

or maybe a micro controller might be the best choice here as it should easily be able to take the pulse and use it for phase comparison and motor speed feedback, a loop filter is simple to code or you could still do it in analogue.

Another option is to cancel the phase lag with a phase lead circuit, also if the motor takes longer to slow down than to speed up maybe you can counteract this effect with a diode in conjuction with the resistor in your loop filter or with phase lead circuit as well.

Colin =^.^=

Reply to
colin

[snip]

Have you considered doing it the other way around?

50 years ago when I was a student at MIT and was teching for the MHD group, I synced all the associated triggering electronics to the smear camera flywheel with a photo pickup (PMT).

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
 Click to see the full signature
Reply to
Jim Thompson

Hello Mike,

Errr, that's not how consultants with good ethics work. At least I don't. A good consultant will look at the problem, figure out a solution and then explain in great detail (and in writing) why he or she did it this way. And possibly also outline why other approaches were not taken.

My clients generally receive a reliable design plus a tutorial. They like it that way. I always ask them whether there is an engineer I could take along through the diagnostic and design phases so next time they'll be able to get going on their own.

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Brilliant. The same concept could probably be used in many other areas.

However it would be nice to have the speed control reasonably stable. This is for the occasions when the lab director walks through. You don't want him to hear the whooping whine as the speed control hunts for the correct speed:) Regards,

Mike Monett

Reply to
Mike Monett

Have you dealt with Labview consultants? Did you read Chris's report on their approach?

Changing to a complicated system that relies on ADC's and DAC's using Windows software is a road to ruin.

My comment stands. Chris has done most of the work already. There is something simple that needs to be fixed.

And I'm certain Chris had a much better handle on the math as well as associated hardware issues such as proper layout and gounding to eliminate noise issues.

He is simply the best person available to do the job.

Regards,

Mike Monett

Reply to
Mike Monett

In my day I didn't speed control the motor. I had built a ~90° phase shifter and two 400W amplifiers (tubes ;-) to drive the synchronous AC motor. Then I brought it up to speed slowly and carefully, tweaking the phase-shifter all along the way.

When I had the speed correct I hit the trigger button and the next time the mirror was in the proper place the MHD tube was "fired".

More instantaneous power than all the power stations in the United States combined ;-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
 Click to see the full signature
Reply to
Jim Thompson

I see little has changed:) Regards,

Mike Monett

Reply to
Mike Monett

Hello Mike,

No.

Yes.

Tend to agree here. That's why I suggested Tim.

Well, he said he thought about handing it off in order to free up some of his time. "...so I can focus on building other subsystems of the project" were his words. Nothing wrong with that IMHO.

Most of the tasks that I am called out for as a consultant were initially thought to be "something simple that needs to be fixed". Some of them were (but not by the staff alone), others had a few hardcore problems underneath the surface. It has happened that clients said at the end "You mean, that's it?". But they would have had a hard time finding it out on their own, for example that #77 ferrite material could not possibly have worked in a certain situation.

From what he wrote it looks like he may not have the time. It might be very worthwhile to secure the help of an expert even if he does it himself. Half a day of help by a consultant can often save a week of trial and error.

Just one example: Had a call from a client at lunch today. They got stuck with the procurement of a few parts. Would have taken them hours to find and they'd have missed today's order deadline, causing a slew of other problems. My billed time was a whopping 15 minutes and for that they got part numbers, source, qties in stock, pricing, and how to find these on their own next time.

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Hello Mike,

Oh, I can already smell a nice exchange of political rants coming up and we aren't even close to elections yet :-)))

--
Regards, Joerg

http://www.analogconsultants.com
Reply to
Joerg

It's like audiophool specs... peak ;-)

But the floor of Building 20 did flex ;-)

...Jim Thompson

--
|  James E.Thompson, P.E.                           |    mens     |
|  Analog Innovations, Inc.                         |     et      |
 Click to see the full signature
Reply to
Jim Thompson

I think the arrangement would be to work closely together, where I would learn how the loop was optimized so I could probably handle future adjustments.

The requirements are not terribly difficult initially. About +/-0.5 degreees jitter is tolerable. But there is another dimension to the project to explore syncing two wheels together. This will need to be about 0.01 degrees p-p.

My problem is that when I did it with a PM motor, it worked very well. Hardware behaved with a few % of the sim. Moving to brushless is faltering, though the circuit is basically the same.

Yeah, that's right, which is why I am surprized it is proving cantankerous.

Mike, it wouldn't be Windows. It would by LabVIEW running on a dedicated real time CPU or FPGA. Windows might be involved at a higher level of "stop/go" that sort of thing.

Don't get me wrong, I still think it's a non-ideal approach.

Hmm. Will have to try a bit harder to see what can be done here.

Thanks for the response.

--
Good day!

________________________________________
 Click to see the full signature
Reply to
Chris Carlen

I didn't mention that two wheels have to be locked together, ie, electronically geared. It isn't that the wheels are being synced to an experiment. Rather, a fast wheel controls an experiment, and a slower wheel gates out too frequent events from the fast.

--
Good day!

________________________________________
 Click to see the full signature
Reply to
Chris Carlen

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