06-12-2014 04:11 AM
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
Questions
Any ideas, help or comments more than welcome, positive or otherwise! : )
Cheers for looking and thanks in advance.
Mitch
06-30-2014 01:29 PM
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.
07-01-2014 01:04 AM
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?
07-01-2014 03:41 PM
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
07-02-2014 01:04 AM
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.
07-02-2014 05:38 PM
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.
07-03-2014 01:19 AM - edited 07-03-2014 01:24 AM
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
07-21-2014 03:48 PM
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