LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

DAQmx - Using same Task multiple times, alone and synced?

Solved!
Go to solution

Hey everyone,

 

I'm looking for suggestions how to implement a Load Cell Task (2 Load Cells in 1 Task - 2 Channel) into a test routine. The details of the test are as follows;

 

The operator is required to secure the part under test, and apply certain loads to the part in 'x' and 'y' directions. There are 2 cranks which apply a compression load, once they read the correct load from LabVIEW they will secure it with screws (ex. 9 kN). Up to this point I have this working fine, now the problem begins.

 

Once the load cells are set to their specified values, the operator wants to start the test and observe how the set load changes over the test duration compare to other parameters like Torque, Shaft Angle, Temperature, ...(Synchronized). 

 

I have both of these functions working separately, but I'm having trouble figuring out how to implement them in the same VI, in sequence. 

 

I am working on solving this problem for the next few days, and will add my code as I make more progress..

Any suggestions are greatly appreciated, Cheers!

Douggle07

 

0 Kudos
Message 1 of 14
(2,645 Views)

It's not clear where you're having difficulty.  Normally I'd expect step 2, where you sync with a variety of other measurements, to be the more difficult part but you seem to think you've got that part figured out.

 

What problem are you running into when you try to combine the two parts?

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 2 of 14
(2,595 Views)

Hey Kevin,

 

I have attached the main VI I am working with at the moment (apologies for the large size and messiness).

My main focus is on the Load Cells Data Acquisition Task, having it run as a setup routine until the operator accepts a load value. Then, the vi waits until the start trigger button is pressed to run the main producer loop with all of the data synced together. I want the value they 'accepted' to be the starting point of the synced load cell data when comparing with other acquired data. Hence, I am trying to avoid restarting the task or offset nulling again and losing the setpoint. 

 

I haven't seen any examples referencing what I'm trying to do here, so I'm just unclear as to if I'm even approaching this correctly...

I'm aware there's also tons of other things that could be improved in this VI, just bear with me for now.

0 Kudos
Message 3 of 14
(2,586 Views)

I'm not using LV 2019 yet, so can you go to the File menu and "Save for Previous Version..." back to LV 2016 or earlier?

 

You make reference to a "producer loop", so I'm supposing you've at least started to think about how to break this problem down into coordinated parallel loops.  I'd recommend a fairly lean & mean data acq loop that produces or publishes its data all the time.

 

The main loop would receive this data as a consumer and can then decide what to do with it.  The main loop could be a kind of state machine.  It would keep track of what "mode" the app is in overall, and make appropriate decisions about what to do with the incoming data (display?  log?  check limits?)

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
0 Kudos
Message 4 of 14
(2,580 Views)

Ok, try this one and see if it opens for you Kevin.

 

I am currently using a fairly straightforward Producer/Consumer setup with a Hardware Trigger and some Data Logging. 

 

The state machine architecture actually sounds great for my purposes. I am getting pushed to run tests on this machine to meet some deadlines unfortunately. Maybe once that settles down I'll have some time to revisit this project and clean up the VI's and overall architecture.

0 Kudos
Message 5 of 14
(2,576 Views)

Oh boy, how do I put this?   Maybe I should use your own words, "I'm aware there's also tons of other things that could be improved...".

 

Um, yeah.  Given what I see, understanding that you've got a deadline, but *also* understanding that untrustworthy test results can be worse than none at all, I'm gonna give you a little outside-the-box recommendation.

 

Solve a different, simpler problem, at least temporarily.  Instead of trying to put all the smarts into your code, focus on capturing all your data correctly and then rely on a human analyst to provide the rest of the smarts after the fact.  Then you can make a simpler program that has only one mode instead of worrying about different modes of operation and how to sequence them.   Just be sure to *also* store the info a human analyst would need to identify which data belongs to which "mode".

 

Now then, on to some specifics.  You said in your original post that you had synchronization working on its own, but it sure doesn't look like it to me.  For example, you shouldn't be configuring several tasks to use an AI Start Trigger (which will only pulse 1 time when the AI task starts) as their Sample Clock signal (which needs to pulse repeatedly). 

 

I *strongly* recommend that you focus on DAQ and sync issues first.  Make a priority of data integrity because "garbage in, garbage out" and all that.  Watch out for the Force Bridge device in particular -- if any device is gonna be tricky to sync, that's where I'd place my bets.  (Keywords b/c not enough time to do a dissertation: Delta-Sigma vs. SAR converters, filter delays, sample rate constraints, sample clock source constraints).

 

Work toward a simple demo app with confirmed sync among your DAQ tasks and *then* get back to the other features and functions.  Be sure you have a good method for confirming sync, there are more ways to get it almost right than exactly right.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 6 of 14
(2,554 Views)

Thanks for the feedback Kevin, this whole project is indeed a 'Demo App' as it's my first time developing with LabVIEW. 

 

I agree with your statements on the importance of DAQ reliability, syncing, and more human interaction instead of putting the 'smarts' into the code, and will work to implement them into the project.

 

I would still like to stay on topic and focus on the Force Bridge Task which acquires data from two load cells. There are some general questions I'm looking to get answered that may help others in the future with similar problems;

1) Is it okay to have two instances of DAQmx Timing, Start Task, and Read VI's in the same task as I have done?

2) As long as I don't clear the task, will the second Acquisition after the second Start Task VI have a starting value of the Last Load Cell value?

3) Is there just a simpler/better way to accomplish my goal?

 

Kind Regards,

Douggle07

 

0 Kudos
Message 7 of 14
(2,535 Views)

I have a little time at the end of the day to come back to this.  First let me briefly answer your 3 questions:

 

1)  Yes.  Because you called DAQmx Stop after the 1st run, it became ok to make 2nd calls to DAQmx Timing (to reconfigure) and then to DAQmx Start.  DAQmx Read can be called as many times as you want or need on a running task.  (It also has an optional "auto-start" behavior that I tend to advocate *against*, preferring reinforce the thought process that goes with handling it explicitly.)

2)  The task will simply report the signal present at the input pins (after scaling is applied).  If a constant load were being applied perpetually, the same signal would be perpetually present at the input pins.  So you could stop and start the task numerous times, and every read call would keep returning the same value (within the margins of measurement error & noise).

    However, if you were to incorporate the built-in calibration function for offset nulling part way into your program, I'm less sure how *persistent* that offset would be across task stop/start or clear/reconfig.  I have generally made my own "tare" operation because then I can also record what offset value was used when doing the scaling.  The calibration function would do an unknown adjustment silently in the background.

3) Dunno about simpler, but have a few minutes to aim at "better".

 

Attached is a stripped down version that focuses on DAQ and sync.  Before getting into the details, take a moment to simply look it over.  Much of my time was spent on tidying things up and making it easier to follow.   See what a difference tidying can make?

 

Here are some futher notes:

 

- I made the bridge device task for the load cells into a kind of master task that the other tasks depend on for timing b/c I kinda assumed it might be a Delta-Sigma device.   (Note: there are also inherent delays when acquiring from a Delta-Sigma device and you may need to compensate for these when you read your data.   I didn't include that part.)

    Note that the master task is the one configured to be triggered and is also started last.   Note too that the encoder task is a little special.  When you start it, any angular motion *will* be registered internally inside the counter even if you haven't started sampling yet.  Just a forewarning in case you see an initial sample that's far from 0.

 

- at first I removed the consumer loop entirely, then later put it back to emphasize the "lean, mean" aspect of the DAQ loop.  All the DAQ loop does is read from its tasks and enqueue the data.  Other processing and GUI display is deferred for the consumer loop to handle.

 

- I tried to simplify your chart and graph code but am not confident I understood your intentions.  So it may not do what you want.  We can come back to that if needed.

  Note that most of the data-handling code in your case structure was duplicated.  I tried to whittle that down so that all the common code stayed outside the case structure.  (Duplicate code has a habit of becoming not-quite-duplicate-anymore after a few late debug & troubleshooting sessions...)

 

- please note, today's an anomaly.  I won't usually have time for extensive followups.

 

 

-Kevin P

CAUTION! New LabVIEW adopters -- it's too late for me, but you *can* save yourself. The new subscription policy for LabVIEW puts NI's hand in your wallet for the rest of your working life. Are you sure you're *that* dedicated to LabVIEW? (Summary of my reasons in this post, part of a voluminous thread of mostly complaints starting here).
Message 8 of 14
(2,516 Views)

Hey Kevin, 

 

Thanks for the detailed response, Kudos for the revised VI!

I agree it not only looks much nicer but simplifies much of what I was trying to accomplish..

 

Using the Load Cell task as the master is an interesting idea, and I also like the idea of adding a 'Tare' VI of some sort instead of offset nulling. 

 

I am acquiring the load cell data via the NI 9237, which indeed uses a Delta-Sigma type ADC with Analog Prefiltering. I'll be testing the machine for most of the day so I'll report back if I notice any significant delay, and any other relevant findings. 

 

Sincerely,

Douggle07

0 Kudos
Message 9 of 14
(2,463 Views)

Good Morning,

 

It appears that style of synchronization won't work for my hardware setup. The VI would run but give errors -209836, and -200303. The first was a sync error, and the second was prompting me to specify an external sample clock for counter 1. 

 

I don't have the option of using an external clock now. The counter card I'm using is the NI 9411, and the Analog Input Card is NI 9239. With this hardware, is there a way around using an external sample clock to sync my tasks for this project?

 

Regards,

Douggle07

0 Kudos
Message 10 of 14
(2,384 Views)