01-27-2012 08:25 AM
I'm trying to acquire force sensor values using an Arduino board (reading the data and controlling a motor) and LabView. The data acquisition rate is tunable according to the motor condition, meaning a high acquisition rate (short delay) during the ON state of the motor and a low acquisition rate (long delay) during the OFF state of the motor.
I managed to acquire the data, but till now I always find some "0" values though I'm applying a continuous force on the sensor. I guess the main problem is the synchronisation of the "datarate" on the Arduino board and the acquisition time point in LabView.
I hope that you could halp me, since I'm trying since weeks to overcome this problem. You will find both the LabView and the Arduino source codes in the attachment.
02-02-2012 02:03 AM
Looking at your vi:
-The Stop button needs to be inside the loop to work correctly
-where do you open/init the comport?
-Why do use local variables? it can all be done with wires, without the danger of race conditions.... (think of data flow )
-in your protocol you should add a termination character so LabVIEW will be able to identify one data block .
it is always possible that (due to EMF or other stuff) the serial stream has an error. So you should check your incomming data (did I receive all expected bytes, are the values correct? Established ways to detect that is a CRC check (in the simplest way: sum up all AD values and add this value (or the last 8/16 bit to the data stream. )
If you can change the Arduino protocol to
and each <Fx>and the checksum is always two bytes you can configure the serial read to always terminate at the \r and use the 15 characters before (decoding is easely done with the 'scan from string.vi)
I would use a producer consumer loop architecture , one loop only capture the data and pipe it into a queue , the next will process the data (error check and display) ....
02-02-2012 09:52 AM
Thank you Henrik for your help.
I'm quite new to LabView, therefore some parts of the VI or some of my questions could be silly or unusual.
I tried to remove al the local variabels, but I'm not sure how to do this for the "load bouts".
The producer consumer loop architecture seems to be a perfect tool for my VI, but I really have no cue how to incorporate this. Maybe one could give me a hint? I'm open to any kind of help; since - as I mentioned above- I'm really new in this field.
Greetings from Switzerland
02-03-2012 04:57 AM - edited 02-03-2012 04:58 AM
Hi, with the shift register you can pass data from one iteration to the next one, by using this, you can remove the local variable "load buts".
Here you can find more information about how this shift register works:
Why are you defining the controls in the front panel as string (for example motor START time or duration motor ON) and then convert them to int? You could define the controls in the front panel directly as int and then convert them to string when you want to write them to your VISA resource. Imagine that your user tries to type some letter in this motor START time...
And the producer/consumer architecture looks really suitable to your application.
Enjoy your first contacts with LabVIEW!
02-08-2012 10:00 AM - edited 02-08-2012 10:06 AM
When using Time Delay, you are reading from the Front Panel milliseconds, and then you are dividing by 1000 and then passing this to the VI express Time Delay, which accept seconds as an input. So you are not passing the good amount of seconds to wait.
That would be easier to use directly the function wait(ms), and you can connect a control in its input to manage the timing of your loop.
How are you doing with your synchronization? Is everything going on ok?
02-08-2012 10:28 AM
the shift register is now working. But I'm still struggling with the producer/consumer architecture.
Do you think it makes sense to divide the read and write processes into the loop with this architecture? I tried several approaches to separate the reading and writing using the COM port as a "queue construct" dividing it for the reading and the writing loop- this didn't work.
Would it maybe make more sense to start the whole thing differently? For example using sequences?
02-09-2012 02:43 AM
With the consumer/producer architecture, I would send to the queue the string that you get from the VISA read, so the rest (create the XY graphs and write to a file could be done in parallel without slowing-down the main loop (in which you are reading from your VISA resource, that way you make sure that you won't lose any data because your processor is executing other operations).
On the other hand, if your timing requirements (read from your VISA instrument) are not so strict, you could create a sequence structure: first read and then analyses, but you won't get any new data until your analyses will be finished, and that can interfere with your read from VISA timing. Instead a sequence structure, use a state machine:
The state machine is much more flexible than the sequence structure.
To sum up, there doesn't exist a single way of programming applications, all depends on your requirements and your way of thinking, I can give you advices, but then is up to you to choose what you think will be more suitable/easy/optimized for your application.
I hope this will help you!
Have a nice day!
02-14-2012 08:46 AM
Hello and thank for reassuring!!!
Unfortunately I'm absorbed by a completely different project. But I will try to proceed with your suggestions asap.
I will let you know, if help is necessary or if I will succeed!
All the best
03-08-2012 01:47 AM
last week I had some limited time, which I could dedicate to my work with Labview. Unfortunately I'm not able to solve the problem with the Consumer/Producer architecture. It seems to be the appropiate solution, but due to my limited knowledge I'm not capable of doing that.
I will add my modifications (CBR control_Prod-Cons.vi) to give you an idea about what I've achieved so far. I appriciate any help of you, since this story is driving me crazy. Additionally, I attach a JPG showing the readout I'm obtaining with the old version (CBR control.vi), where the red circles indicate the problem with the "0" values.
Thank you again,