From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why can't I run this faster?

So let me start off by saying I have very little LabVIEW experience, and this code is the result of me playing around on my own for the last couple months. I haven't had any actual training so my understanding has been gained mostly through trial and error. That said, it's very possible I'm missing some understanding of key features that might easily solve my problem...

 

Anyway, here's the issue: I've coded a simple on-off, ramp/soak controller to power two small heaters. Right now it works but is very slow. What I mean by slow is that the code inside my loop takes around 1.8 seconds to run. What that means is if I set the sampling time to under 1.8s, the loop doesn't run at consistent increments, as some times it has to wait for two multiples of 1.8 to pass instead of just one. 

 

Does anyone see any obvious ways to speed this up? With the sampling time so high I get a lot of overshoot and waviness in my temperature response..

 

Any help would be greatly appreciated!

 

 

More details incase they're helpful:

 

Thermocouple Input DAQ Assistant - Takes in 3 thermocouple values from an NI 9213, acquisition mode set to On Demand

Digital Output DAQ Assistant - Outputs a Digital Line Output to the heaters via an NI 9472, generation mode set to On Demand

DAQ Assistant outside of the loop - Just there to make sure the heaters are turned off once the profile is complete

Download All
0 Kudos
Message 1 of 11
(2,856 Views)

What is inside of the PID VI?  I'm not seeing anything blarring on the top-level VI.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 11
(2,843 Views)

It's the built-in PID Setpoint Profile VI. I've attached the block diagram for you. It's a little above my current comfort level, but I don't think it's the problem as it's a built-in function and works much faster on the examples I've looked at which use it.

0 Kudos
Message 3 of 11
(2,832 Views)

 

I would try benchmarking the hardware interfaces to see how long they take to perform their measurements. Use a tick count or get date/time in ms with a feedback node to compare the current/previous timestamp for the loop to see how long each loop takes (and reduce the execution timing - your wait until ms multiple) and then try enabling/disabling your various hardware interfaces to see which one is taking a long time.

 

There are, of course, lots of other debugging methods that can help you troubleshoot the issue (probes, highlight execution, VI profiling).

 

If it is the hardware interfaces that's taking a long time, you could try using the DAQmx drivers to read from your hardware instead of the Express VIs. This will allow you to initialise/close the device outside the loop which will increase performance.

 

As a final point - you're using wait until ms multiple timer VI which means that if it takes longer than 1.8 seconds to execute, the loop will take 3.6 seconds to execute instead (as it rolls up to the next multiple of the input value)!


LabVIEW Champion, CLA, CLED, CTD
(blog)
0 Kudos
Message 4 of 11
(2,808 Views)

Please post your actual code instead of pictures so we can see how you have the acquisition, etc. configured.

 

Kelly Bersch
Certified LabVIEW Developer
Kudos are always welcome
0 Kudos
Message 5 of 11
(2,777 Views)

Kelly - Here's the VI

 

Sam - I tried converting the DAQ Assistants to DAQmx tasks and it didn't seem to speed things up very much. I'll take a look at some of your debugging ideas though.

0 Kudos
Message 6 of 11
(2,742 Views)

Try changing the Wait Until Next ms Multiple.vi to Wait (ms).vi.  As it is now you have it set to wait until the next 1800 ms multiple.  If the operation takes 1801 ms it will wait till the next multiple.

 

What happens if you don't wire the dt input to the PID and let it figure out the timing on it's own?  Then you can just set the minimum loop time using the Wait (ms).vi.  Also, try initializing the PID on the first iteration of the loop.

 

Kelly Bersch
Certified LabVIEW Developer
Kudos are always welcome
0 Kudos
Message 7 of 11
(2,721 Views)

I got it down to around 1s - I realized I was reading in temperature from 2 different TC modules and by switching all the TCs to the same module it seems to have cut the runtime in half.

 

Here's my next question: Is 1 second reasonable? Should I be able to go faster than this? As a LabVIEW novice I don't know what to expect, and I don't want to spend time trying to speed things up if it's just not realistic..

 

EDIT: I also tried removing the "wait" and the "dt" entirely, and it got the time down to ~970ms. However without a dt constant the x-axis of my waveform chart comes out wrong..

0 Kudos
Message 8 of 11
(2,714 Views)

I'm wondering if it is the DAQ Express VI that is slowing you down.  Afterall, it has to setup and close the DAQ task each time it is called.  Use the actual DAQmx API to setup the read and writes.  I made some edits.  See if this helps any.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 9 of 11
(2,701 Views)

Not sure what modifications I need to make, but as is it's not working properly. The TC data all shows up as 0 on the chart, and when I stop to program I get the attached error message...

0 Kudos
Message 10 of 11
(2,687 Views)