PID and PWM via 9401 TTL DIO Module

[Mitch_Peplow]

Hi all,

Right I need some help with a little rig that I'm building to create a PID term calculator. The rig consists of a simple brushed DC motor and an optical pickup for the speed. The motor will be controlled by Pulse Width Modulation.

Both the PWM and speed pickup are fed out/into the NI 9401 High Speed TTL DIO Module. The TTL signals drive a MOSFET for PWM control and an opto-isolator for the speed input being as they are 5V logic levels. The modules are sat in the legacy 9172 cDAQ which for clarity I will point out only has 2 counters, one of which I'm using for the PWM, the other for the speed input.

Now, I also want to incorporate the auto-tune PID feature as a) it intrigues me as to how good it is; b) I've never used it so want to and c) use it as a comparison compared to the calculated values.

So, I knocked up a quick VI (attached) to test things and that’s when it became apparent that it may not be as simple as I had first hoped. I’ll go through each issue then ask a few questions to start the topic off.

Issues

1. The number of samples per channel seems to indicate how many pulses/cycles it needs to see before returning data, however this means that the loop time and thus responsiveness and quality of control is directly related to how fast the motor is spinning and the requested number of samples. The samples must also be gathered within the timeout time otherwise default data is returned which the PID acts upon.

2. Lowering the number of samples per channel seems to cause two issues. The first is that there are not enough samples to gain an accurate speed reading; the second is that the duty cycle property node cannot update fast enough and so it throws an error. It does however mean that the control is more responsive as we are iterating faster.

3. For some reason, using the mean data for the speed does not give the correct value. It’s always either higher than the actual speed or it returns a value completely out of the bounds of the motor. The motor is rated at ~2,300RPM no load but I either get values that are say 20-50RPM higher than the actual or silly values like 5,000-7,000RPM. Using the first element of the array data gives the correct speed which I have verified with a hand help optical tacho.

Questions

1. Is there a better architecture and/or control setup to use for this simple piece of code if the fundamental issue is the fact that control is dependent on how quickly the number of samples can be gathered? Even if the tasks were split into separate loops, as I see it, the issue would remain as the PID loop, although now allowed to update before the samples have been gathered, would be basing its decisions on old data. Hope that makes sense.

2. Why does my mean data not match the first index element and why does it sometimes output erroneous values well in excess of the motors capable magnitude?

3. The use of the property node to change the PWM was taken from the shipped NI examples. Is this the only possible way change the PWM on the fly with this module/chassis?

Any ideas, help or comments more than welcome, positive or otherwise! : )

Cheers for looking and thanks in advance.

Mitch

[Lewis_G]

Hi Mitch,

1.What you are describing is the "implicit" sample clock.  Your acquisition doesn't act like a normal clocked input because the counter is essentially the clock. You only get a new value every time you get a rising edge on your input.   The the DAQmx timing VI will explain it better than me.  By having your samples per channel set as 3, I think you are asking it to wait for 3 new rising edges.

I think I would have my counter input in a loop running separately at a faster rate than my control loop.  Then share the latest input frequency with the PID loop via  a local variable.

3.  You can use the DAQmx write with counter selected on the polymorphic instance.

I would read up on the counters section of the 9172 manual. Investigate whether you should be using  Low Frequency with 1 Counter or High Frequency with 2 counters.  Make sure the cDAQ is capable of keeping up.

Sorry im not much help here.  I'm interested to find the solution to this also.

[Mitch_Peplow]

Hi Lewis,

Many thanks for taking the time to reply, much appreciated.

Unfortunately the counter sample clock has to be set to implicit; it’s the only option that allows the code to run and any other selection results in an error being thrown stating exactly that. What I don’t know however is if an external clock source could be used as a workaround rather than using the internal time bases.

As you say, splitting the tasks may help if the sampling method could change, however being as the output PWM is based on the measured input frequency the two are inherently linked so I’m not sure how much benefit would be gained by doing it. Also, because of the way in which the clock is working (as you described perfectly) separating into two loops would yield no benefit as the output would still be as clunky as if in one loop and potentially worse if having to use a local variable. If I do go down that route just to see what difference it makes ill just use a simple producer consumer architecture.

Regarding the 9172 manual, I've already read all the counter material to try and establish the accuracy using one counter remembering that the 9217 only has two counters in total. I'm having to use one for measuring the input frequency and the other to generate the desired PWM output thus I'm limited to 1 counter regardless. Here is the table taken from the manual regarding accuracy for one counter:

I'm running at 3kHz maximum and when working out this gives me an error of 0.00375% so well within tolerance. I've also injected 200kHz into the system and it was rock steady to within the given tolerances so counter wise I'm happy using one, its more this issue of the clocked input being the actual clock.

What I currently do, which was advised by NI and also done in their shipped examples, is to set the number of samples to -1 such that you read all available samples then set a time to the ‘wait until next ms multiple’ timing VI. I use 50ms as this seems to be enough time for the input to be read and the PWM property nodes to be updated.

The issue of the mean value appears to be down to noise as the circuit is picking up artefacts of the base frequency. This can clearly be seen if changing the base from 1kHz to 10kHz and 100kHz. I'm currently in the process of fully shielding all cables, boxes and building a dedicated PCB board for this task to eliminate any electrical interference. Even the 9401 manual states that not using the suppression ferrite causes noticeable degradation in signal, i.e. dropout of missed/false values as its digital!

Any thoughts or comments?

[Lewis_G]

The logic behind using a local variable is that you can define the rate of your control loop and it will always get the "latest" frequency from your DAQ input loop.  however, this is a bit pointless if your control loop is getting stale data. I think setting the number of samples to -1 like you said is a better idea.

If you had flawless results when injecting a 200Hz wave then that tells me that your code is OK.  I would get an oscilloscope on your input signal to see what your counter is having to deal with.  I think you might see noisy signal which is why you are seeing erroneous data.  Make sure you are hitting the logic levels of the 9401.

Let me know how you get on

[Mitch_Peplow]

Morning Lewis,

Well this is the thing, I’ve had a scope on the input and it is indeed noisy which is why I decided to take a step back and improve the hardware side. Even some simple alterations made significant improvements and the speed input was the cleanest it’s ever been. The issue I’m not so sure will be cleared so easily is the issue of the base frequency residing in the speed signal.

The other issue I’m struggling to get working is the auto tune function in that it doesn’t appear to output anything useful nor stop once started. All of the options either make the motor do nothing or just act silly or return ever changing values. Have you ever used the auto tune VIs?

To me the help file doesn’t provide enough definitions as to what effect the type of technique and amplitude settings have. This motor responds instantly with no lag whatsoever so in my mind I need to set the controller to PID and the control spec to fast. Any ideas or help/tips with the auto tune function?

I should have the modified hardware finished by the end of today so I’ll give it a go and let you know.

[Lewis_G]

I have used the Auto Tune VIs.  There are basically 2 ways of estimating the dynamics of the system:

1.  Put the system into oscillation by increasing the gain.  When you are in a stable oscillation, you can characterize the response and then estimate the PID gains from it.  

2. Give the system a step input.  Characterize the response and then estimate the PID gains from it.

Take a look at my UAV and in particular the Test Bench part of it.  You can see how I use them there.  The main difference with me is that I manually generate step inputs or put the system into oscillation and then let LabVIEW calculate the gains based on the response.

[Mitch_Peplow]

Hi Lewis,

I didn't manage to finish the hardware yesterday due to other work taking priority and I'm on holiday tomorrow and all next week. Ill have to pick this back up when I return so please don't think I've lost interest.

Ive looked at the link you sent for your UAV and that looks like a top class project; you clearly know what you are doing. Ive downloaded the code but not had a chance to look at it but I'm guessing it contains the answers I need around the auto tune VIs. Out of interest though (and somewhat laziness) are you saying that you must manually induce an oscillation for the auto tune to work as that seems counter intuitive to me as in my mind auto means sit back and have a coffee whereas it seems from your description (and YouTube video) that auto simply means it automatically calculates PID values based on impulse responses?

Regarding the estimated values for the PID gains, this is what I have been trying to do in order to a) provide a comparison to what LabVIEW calculates and b) create a PID calculator VI based on the system dynamics rather than using my special PID calculator (two dice and a big slice of luck )  What calculation do you use for your PID gain estimates and do your calculated values come close to what LabVIEW calculates?

Cheers again for all the help

[Lewis_G]

I think you can get it to tune automatically but I'm not 100% sure.  I think I did it myself so I had more control over what was going on.

I've sent you my dissertation which explains much of the theory and should help you out.

Cheers