LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Where to put communication with NI USB-6212

Solved!
Go to solution

My application works perfectly using my example in the zip file:

http://forums.ni.com/t5/LabVIEW/Where-to-put-communication-with-NI-USB-6212/m-p/3255752/highlight/tr...

 

Zip up your actual project, and post it here. I can have a look what you do wrong.

 

 

 

0 Kudos
Message 31 of 40
(1,654 Views)

Wait!

0 Kudos
Message 32 of 40
(1,648 Views)

Do not be in a rush, now I go for lunch, can have a look after 🙂

Hints: did you check the proper dev# numbers were used for the Init (and also inside the init case, for the DIO device number constants)?

Did you ensure proper execution order using the error wires, like in my example project?

0 Kudos
Message 33 of 40
(1,642 Views)

I think that's not the problem.

Seems that the error only appears when I copy the 2 vi’s into 2 separate vi’s and run them separately.

When I call the 2 vi’s from the same vi, there is no error. Not now at least Smiley Happy

0 Kudos
Message 34 of 40
(1,636 Views)
Well, you create the error since you try to reserve the same hardware from two separate VIs. What you do does not make any sense.
0 Kudos
Message 35 of 40
(1,629 Views)

Since you did not show your project, I can only guess what is going on. You can only reserve the required hardware channels from LabVIEW for a DAQmx task once. I think what you tried, you tried to reserve it two times in the two VIs. Naturally it will result in an error. Just think about what you do: you run the Init function to initialize the hardware. Then you call again the same init function from another VI, i assume. Since the HW is already "busy", the second Init function will throw an error...

 

If you explain what you try to do, why you need to run two VIs separately, we can suggest another solution.

First of all, you should always use a LabVIEW project to contain all your subVIs, type defined controls, and usually one single main, "top level" VI what the user sees when the application runs.

Of course you can use my hardware subVIs (located inside the LabVIEW library, lvlib) at different places in your main VI, but you need to ensure that you only initialize ONCE in the beginning (for example in the init state of a State Machine). After initi happens, you can use the AI Read and DO Set functions free from the lvlib anywhere in the VI. When you stop the main VI, you must use the Close function to RELEASE the hardware resources.

 

So to summarize, the problem is not in the lvlib functions, but in your actual LabVIEW design.

0 Kudos
Message 36 of 40
(1,613 Views)

Thank you for your reply.

I don’t I’ll think I manage now.  I can’t reproduce the error I min Vi from before. Sorry for having trouped you.

By the way it was a very good course I was on. I learned a lot. But I will not show you my vi before at the moment. There are too many things to criticize.Smiley Embarassed

0 Kudos
Message 37 of 40
(1,596 Views)

No problem, you can only learn via mistakes and trials.

What is important to get familiar with the most important concepts in LabVIEW, like data flow. Beside, design patterns are very important, like how to use State Machines.

Have nice learning!

0 Kudos
Message 38 of 40
(1,592 Views)

Hallo Blook

I need to ask at question.

My volt using you app is not stable. Think I need to increase the sample rate to eg 100 kHz.

But how?

Using “wait “ at 1 ms only gives med 1 kHz. How can I increase the number of loops?

 

0 Kudos
Message 39 of 40
(1,547 Views)

Define what "not stable" means. Compared to what? You mean the measured pressure value (voltage output of the sensor) is not stable? Quantify it! What is the standard deviation of the measured signal? Do you have a datasheet for these pressure transducers? What is the specified accuracy, noise level, temperature sensitivity? First you need to study your hardware, then you can make clear statement about your expected signal. Also, do you use electromagnetically shielded signal cables? Grounding is properly done?

 

I do not think increasing the sampling rate will help you with the noise. You can "increase the statistics", and take an average of the signal in this way, lets say you can smooth your signal curve. But do not forget there is a certain "error bar" always, so you need to be aware of smoothing.

 

About the code: it looks like you still did not learn an important part of LabVIEW which is timing. You should understand what software timing means, and what are the limits.

"Using “wait “ at 1 ms only gives med 1 kHz. " No wonder, if you take the reciprocal of 1 msec, you get 1 kHz 🙂 You cannot go faster with software timed loop than 1 kHz, and even worse, at this level you can have few msec or higher differences between iterations.

 

I repeat, if you see an unstable signal, you should quantify it and compare it with the datasheet (you could attach your signal and also the sensor's datasheet). Then you can try to find the reason and how to fix this problem. Just simply increasing sampling rate will not solve the source of the problem. And after all this, if you still need higher sampling rate (I doubt), you need to learn how to do hardware timing using DAQmx functions (my code simply does software timing, since it runs only at 1Hz). There are lots of examples coming with LabVIEW showing good practices.

0 Kudos
Message 40 of 40
(1,543 Views)