2-Channel Output Based PID From Voltage Input

[kckincaid]

Hello all,

I apologize in advance, I am fairly new to LabVIEW and have been struggling to get this VI working for several weeks now. I have scoured the forums and the example VI's to no avail, and am reaching out for help now since I need to get this done soon.

The Hardware:

- NI cDAQ 9174 (4 Slot DAQ)

- NI 9201 (Voltage Input Module)

- NI 9263 (Voltage Output Module)

- NI 9237 (Bridge Input Module)

The Goal:

I am attempting to build a VI that reads in an angle measurement from a hall sensor and converts the voltage reading to degrees. This reading is averaged to remove some noise, then sent to a PID controller, which should move a linear actuator back and forth using two channels (one for forward, one for reverse). Additionally it reads forces from a load cell, but I have removed most of this section of program in the attached VI since it works fine.

The Issue:

I have the voltage input, conversion to degrees, and PID sections of the program working well. However, I am having no luck getting the output to function as it should. I don't think it is outputting anything at all, as far as I can tell. I have tried a great number of combinations and permutations of the DAQmx Start Task, Sample Clock, etc. VI's, as well as order and placement relative to the while loop, but nothing seems to work. I don't think the example VI's shipped with LabVIEW help since they don't illustrate simultaneous I/O.

Any advice, tips, etc. would be most appreciated. I am very unsure of what I'm doing wrong and need some direction.

Thanks,

Kellis

[JÞB]

These sounds like a DAQmx understanding problem.   I can often help.  However, I am updating NI Software this weekend and cannot open a vi.

Do you know how to post a snippet? Please show the DAQmx write vi and discuss any hidden code in other cases not shown.

[kckincaid]

Jeff,

Thanks for the quick response. I've attached 2 .png files of the block diagram (they overlap some). Is this what you need?

FYI, in this version I've removed the sample clock from the output task, as the post below said it can sometimes mess with the output.

https://forums.ni.com/t5/LabVIEW/Error-200462-Generation-cannot-be-started-because-the-output/m-p/22...

Thanks,

Kellis

[JÞB · Accepted solution]

Close enough.   Probe the error chain on the AO Task.  Then delete the first write ( and the start task) that is throwing the error because the first write is writing an empty array.  

DAQmx write n ch 1 sample expects a 1D array with value in it. And bonus the Autostart property, default  TRUE, will start the task just fine.

[Kevin_Price]

[EDIT:  Between starting to answer and coming back to finish & post, Jeff *did* come back with an answer.  I've gotta start remembering to refresh my view when I return to a half-finished post.]

1. Check your error wires.  Have you placed debug probes on them or run in execution highlighting (slow motion) mode yet?    More generally, your code should notice and react when any of your DAQmx tasks produce an error output.

2. Have you probed the 2 values you are attempting to write each loop iteration?

3. Have you probed the boolean values that control the case structures that help decide what values you attempt to write?

Catching the theme?   There's really not a lot of code here.  A handful of probes (or temporary GUI indicators) would provide a lot of clues.

Jeff may be back to make a guess with his magic 8-ball.  Meanwhile, my best guess is that your attempt to write an empty array before starting the AO task produces an error.  Then this error carries through to the calls to Start and Write in the loop, causing them to bypass their normal functionality and do nothing.

-Kevin P

[JÞB]

Kevin, 

Those are some good guesses!  Have you been operating a Magic 8-Ball?  

And yes, write "1 sample with nothing" is an error and produces one every time.

[kckincaid]

Jeff and Kevin,

Thank y'all for your help. Following Jeff's directions about removing the Start Task, extra Write VI, and autostarting the main VI, I was able to get the program to work! I've attached a snapshot of the modified VI for anyone else who might run into the issue.

Another issue, which I thought I should post here instead of making a new thread. There is a significant amount of noise in the angle measurement. Part of this may be because I'm only using a small part of the range of my Hall Sensor, so small changes in the supply or output voltages have a larger-than-normal affect. I've tried using a point-by-point Butterworth or Mean filter on the angle, but both of these introduce a non-negligible time lag that messes with the PID controller. Is there another method I could try to reduce noise?

[EDIT]: I think I should include that I am (attempting to) correct for variations by measuring the supply voltage, creating a ratio of output to supply voltages, and comparing that to ratios measured at known angles to generate my "actual" angle. [/EDIT]

Thanks,

Kellis

[JÞB]

---

@kckincaid wrote:

Jeff and Kevin,

Thank y'all for your help. Following Jeff's directions about removing the Start Task, extra Write VI, and autostarting the main VI, I was able to get the program to work! I've attached a snapshot of the modified VI for anyone else who might run into the issue.

Another issue, which I thought I should post here instead of making a new thread. There is a significant amount of noise in the angle measurement. Part of this may be because I'm only using a small part of the range of my Hall Sensor, so small changes in the supply or output voltages have a larger-than-normal affect. I've tried using a point-by-point Butterworth or Mean filter on the angle, but both of these introduce a non-negligible time lag that messes with the PID controller. Is there another method I could try to reduce noise?

[EDIT]: I think I should include that I am (attempting to) correct for variations by measuring the supply voltage, creating a ratio of output to supply voltages, and comparing that to ratios measured at known angles to generate my "actual" angle. [/EDIT]

Thanks,

Kellis

---

Different problem.  Create a new thread.  Although,  you are right on the money! You have the wrong sensor.  What model and do they have one with a smaller dynamic range?