03-23-2016 05:52 AM
My application works perfectly using my example in the zip file:
Zip up your actual project, and post it here. I can have a look what you do wrong.
03-23-2016 05:56 AM
Wait!
03-23-2016 05:59 AM
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?
03-23-2016 06:02 AM
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
03-23-2016 06:06 AM
03-23-2016 07:22 AM - edited 03-23-2016 07:24 AM
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.
03-23-2016 09:22 AM
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.
03-23-2016 09:27 AM
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!
07-05-2016 04:30 AM
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?
07-05-2016 06:33 AM
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.