LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview temperature PID control w/ NI 6211

I like to leave the gains and setpoint outside of the while loop for tuning purposes. I used a similar VI as a subVI in a larger tuning application where I was playing with genetic algorithms (not using a while loop, obviously). As far as the error wires are concerned, I like to use one error wire for each DAQ task and merge them at the end. It helps me keeps the tasks organized. The sequence structure is unnecessary, but then pobodys nerfect Smiley Wink

 

Good suggestions though. Moving those controls inside the while loop will make it much more useful as a top level application, rather than a subVI in a larger block of code.

John B.
Embedded Networks R&D
National Instruments
Certified LabVIEW Developer
0 Kudos
Message 11 of 18
(2,024 Views)

@JtotheB wrote:

I like to leave the gains and setpoint outside of the while loop for tuning purposes.


That's exactly why the gains and setpoint should go inside the while loop: so that you can tune it while it's running.  Otherwise you'd have to stop and restart the program every time you changed the gain.

0 Kudos
Message 12 of 18
(2,005 Views)

Sorry for the delayed response.  Yes, I think I would like to leave those values inside the loop to continuously tune my PID controller.

 

When I run my program now, I get the following error message:

 

"Error - 200745 occurred at DAQmx Start Task.vi:12

 

Possible reasons: Frequency and Initial Delay property values are inconsistent with one or more counter timebase properties.  The conflicting properties must satisfy the following constraints:

 

Counter Timebase Rate / Counter Maximum Rate <= Frequency <= Counter Timebase Rate / 4

Counter Timebase Rate / Counter Maximum Rate <= 1 / Initial Delay <= Counter Timebase Rate / 2

 

If the counter timebase rate is not specified, it is inferred from the Counter Timebase Source selection."

 

Unfortunately, I do not know how to specify a Ctr Timebase Rate myself...I do not see anywhere to wire it on the DAQmx Timing or Create Channel VIs.  Does this have something to do with me not using a sample clock?  Help!

 

- T

 

P.S.  Values given in that error message for the above parameters are:

CO.Pulse.Freq = 100e3

CO.Pulse.DutyCyc = 500e-6

CO.Pulse.Freq.Initial Delay = 0

CO.CtrTimebasesrc=80MhzTimebase (not sure what this parameter is...)

Co.CtrTimebaseRate = 80e6

0 Kudos
Message 13 of 18
(1,980 Views)

Can you upload your current code?

0 Kudos
Message 14 of 18
(1,976 Views)

Yes sorry, here it is.  I am also having a little difficulty understanding what is going on with the error wires, if an explanation is available.

 

Thanks again.

 

- T

0 Kudos
Message 15 of 18
(1,971 Views)

Actually, the error message is fairly helpful.  It's telling you that you're trying to write a duty cycle value that is too small, in a roundabout way.  The value you're writing is 0.001.  The timebase is the 80mhz internal clock.  You have the frequency set to 100000hz, so each cycle is 80,000,000 / 100,000 = 800 clock ticks.  A duty cycle of 0.001 x 800 = .8, or just less than 1 clock tick.  The minimum, according to the error message, is 0.025 (800 x 0.0025 = 2 clock ticks).  You can solve this error by using a lower frequency (do you really need 100khz?) or increasing the minimum duty cycle (one of the inputs to In Range and Coerce).  Whichever way you do it, you can't set a duty cycle less than 2 clock ticks.

 

Once you solve that you'll get another error from Wait for Next Sample Clock, which only works for single-point hardware timed acquisition.  See the help for that function; it notes "National Instruments recommends you use this VI for certain applications only" with a link to a list of those certain applications.  My guess is that none of that applies to you, in which case you should remove it and use a normal timing mechanism such as Wait (ms).

Message 16 of 18
(1,965 Views)

That makes a lot of sense, what I did not understand is where the 80MHz came from...I changed the frequency to 1000Hz and it seems to have fixed that issue.

 

Since I already have a Wait function in my code (bottom left corner), should I just remove that Wait for Next Sample VI entirely, and run the wires directly to the Clear Task VIs?

 

- T

0 Kudos
Message 17 of 18
(1,961 Views)

@thimz wrote:

 

Since I already have a Wait function in my code (bottom left corner), should I just remove that Wait for Next Sample VI entirely, and run the wires directly to the Clear Task VIs?


Yes.

0 Kudos
Message 18 of 18
(1,958 Views)