Sincronize 3 Visa reads

[cstorey]

Why is the data LVM?  What version of the code are you using to collect this? 

It doesn't look like data format from the latest code I posted.  Unless you run with a recent version of the code that I posted I don't think anything will be synched!  

Please try to modify the software as I suggested, run and save that data and post a file.  If you have a problem modifying or running the code I posted please let me know.

Craig

[MrBadgerBR]

The 'Write Delimited Spreadsheet.vi' is not avaiable in Labview 2013.

So I change it changing for the old block (red circle). I attached what I did here.

And sorry for this, but I just saw your solution block now.

I will try to redo it here and run the program again.

[MrBadgerBR]

Well I tried with .csv and I didn't think that I know how to read this in Matlab.

I put the .csv with semicolon as delimiter.

And the sensor isn't sincronize with the others.

With that said, I change the sensor order to see if is a code problem or a sensor problem. Putting the USB sensor at sensor1, the error continued the same. So I will try to find a new one to be sure of this problem, but I think the problem of the sincro is done for the bluetooth ones.

If the USB sensor is faster than the others, I couldn't understand why it would be faster in the data if you put timestamp for the event. Maybe isn't a thing on windows of read USB first of Bluetooth? I am saying that because I think it would be more data if the sensor if faster then the other ones but the event would be sincronize because the time was the same. Am I wrong?

And I don't know the firmware of the sensors, but the hardware of them are the same. The same flow sensor and the same family of pressure sensor. The usb is a 1PSI sensor and the bluetooth are 5PSI.

What could be this sincronize problem? Any ideas?

[cstorey]

Here's what's in the datafile attached..

"4,224;6,276;6,276;6,276;6,276;6,276;6,276;6,276;6,276;6,276;6,276;6,276;6,276;6,277;6,277;6,277;6,277;6,277;6,277;6,277;6,277;6,277;6,277;6,277;6,277;6,277;6,277;6,277;6,277;...."

That datafile makes very little sense to me, there are "," and ";" an the data is integer not double as it should be for time and your readings.  I think you need to avoid that Dynamic Data - Signal File save Express VI.  I'm not sure what its doing to your data but it doesn't seem good.  And its delaying progress.

Here's a new version of the code that will generate a tab separated txt file.  Please try to run it , then post the data here.

Craig

[MrBadgerBR]

I will try it now here.

I think that the problem is my language.

In portuguese-Brazil, the comma and dot in math change the meaning.

So hundred thousand dolars and fifty cents is U$100.000,50 in portuguese and U$100,000.50 in english.

I think I can't change this because is the configuration of the Windows.

Maybe that could be one of the problems to understand the data.

But let me just build up the settings here and I post the result.

[MrBadgerBR]

Well, as I said, the comma is the english dot for math that as a separator of decimal numbers.

The files are here.

Flow from Labview

Flow from Matlab

Pressure from Labview

Pressure from Matlab

[Albert.Geven]

One of the bugs in LabVIEW at least as I see it is the default of using the localized decimal separator.

In the Netherlands we have the same problem you have , and decimal point are swapped from USA.

So the only real important setting I change in LabVIEW is uncheck the default Use localized decimal point.

You can find this setting in Tools/Options/Front panel  second line on the left.

[cstorey]

Ok, file data looks good.  It looks like all sensors start about the same time but the USB sensor reads less frequently.

Try not subtracting initial time, just using time stamps.  Modify the get_data.vi to remove time subtraction and go back to GetDateTimeSeconds time stamps.  I want to see if the high resolution timer is working well in 2013.  If you need help let me know.

Craig

[MrBadgerBR]

Sorry for my delay to answer, but I remove the subtraction and it was horrible.

When I remove the subtraction and got the time from outside of the vi, the from that sensor was horrible. I couldn't see the other two because the plot was to big. The time wasn't what we could expected for.

When I got the data from inside the block, the same occur. The same was so big that we can't see what is in it.

So, just to show what I mean as to big, here is the plot.

I really don't know why the usb is becoming faster but change that time stamp didn't help.

[cstorey]

I don't think there are any sensor issues, just a lag in the start of the Bluetooth sesnor initialize that needs to be accounted for.  Also, I was thinking of using a timestamp and making sure that noting starts measuring until all sensors are initialized.  Like this.. (please try and post data afterwards)

  Now that I know more about what you are doing I don't think the hight resolution time is required, or is the right VI for your application.  It might not work over long term measurements as the Help states..

Note  The operating system clock this VI uses is not tied to any absolute time reference and may drift over time when compared to absolute time sources. Avoid using this VI across long periods of time.

Hey NI - a definition of what LONG is in this context would be nice!  A few plots of expected drift vs. time perhaps?  I'm sure its been done during development. 😉