Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

Problem communicating with Inertial Sensor

hello ninlmartijn,

 

yes you are right, the typecast data should be C2 instead of CF. Sorry for that. I was trying out with the CF command (to read the euler angles and angular rates) earlier. I am sending  you my program which is for the CF command. 

 

I have tried putting the "wait vi" just as you suggested but unfortunately the timer values obtained are still very weird, as shown in the screenshot 1 I have attached (the x-y array). Screenshot 2 shows a rather better timer values but still have a 'glitch' value (-202.522). Any idea/opinions on how to overcome this problem?

 

By the way, I am Lawrence and I am from Malaysia. Nice to meet you. 🙂 

 

 

0 Kudos
Message 21 of 28
(2,077 Views)

Hello All,

From everything you guys have mentioned in the previous posts I am not sure if you will be able to get the timing consistency you need. It seems that you are looking for determinism, which GPIB and pretty much any other instrument control protocol is not. Another item that may be causing a problem is the operating system that is running,there are usually other processes running in the background that will slow things down. Operating Systems like Real Time were made to reduce the jitter and be more deterministic. 

Some things you can probably do to reduce the jitter that you are having is to change your code up a bit. I see that you are using an high level vi to write your data to a file. Normally this is not a problem, but by placing it in a while loop you are opening and closing the file to it consistently. If you change this to lower level vis, you can open the file at the before and close it after the while loop. Other than that, I would advise having the least amount of applications open on your PC while running the code, and this includes anything that may be running in the background.

 

Hope this helps

Can Wong
0 Kudos
Message 22 of 28
(2,062 Views)

Hello Lawrence,

 

Really nice to meet you to. I wasn't in the office till Friday, and on Friday I didn't had the chance to look at our problem. The timer values are provided by the sensor, so there shouldn't be a problem with latency or time instability between computer and sensor or operating system. If you are taking continuous measurements there was (or I thought I red about it) also something of a continuous mode. Then you don't have to send a read command to the sensor and the sensor send continuously the measurements to your PC. But I recommend first to get this work 😉

 

I suppose you are getting the time difference between two samples (delta x (or t). First thing to do is to check if the time in the string is correct. I adjusted your VI and made a sensor time array direct after dividing. The counter times should be in this array (values between 0 and 218). Please look if the values in this array are correct.

 

I hope the values in this array are correct. I thought of another way to get the right time differences between the measurements. What I did is subtracting the new counter value with the previous counter value. There is a problem when the counter flips over (starts again after 218), so I build in a case structure; when the subtraction of the new value and the previous value is below zero I add 218 with the new value (so if previous value is 217 and the new value is 2, 2 is added with 218 and subtraction is 220 - 217). This I could test and worked fine.

 

I hope this will help you further, please let me know,

 

Best regards,

Martijn S
Applications Engineer
NI Netherlands
0 Kudos
Message 23 of 28
(2,034 Views)

woot! thanks for your suggestion ninlmartijn, the timer works perfectly in my program :D. You are awesome!

 

I have one last question. I realized that if i remove the VISA close vi from the last frame of the stacked sequence, it would improves the sampling rate alot. Right now my sampling rate is only about 8 samples (data) per second, as opposed to the 'desired' sampling rate of 100 samples per second. Once i remove the Close VISA vi, the sampling rate would be very close to the ideal one. However the program would stop acquring data from the sensor after some random time and the timeout error message will be displayed.

 

Is there a way which allows me not to run the VISA close vi everytime the While Loop executes? I have tried setting the timeout (msec) at serial configuration vi to a very high value (around 1000000) and it doesn't help much. 

 

Thank you very much and hope you have a great day ahead. 

0 Kudos
Message 24 of 28
(2,013 Views)

Hello Lawrence,

 

Great to here that everything works, we solved the puzzle! Smiley Very Happy

 

It is best to  keep the VISA close outside the While loop. Use (most important) VISA set buffer size.vi (before the loop) to create a buffer. If you don't set a time out, the default time out is 10 sec.

If we want to be sure that your loop returns on time to visa Write and Read, we make two parallel loops; producer consumer loop (one for VISA read/write and one analysis). The VISA loop will write and read on a certain speed; the time left on the CPU will be used for analysis please have a look at the following tutorial.

This means a big change in your VI, I would recommend this only when the simple modification keeps produce time outs. Good luck with your measurements, and your report!

 

Best regards from the Netherlands,

 

 

Martijn S
Applications Engineer
NI Netherlands
0 Kudos
Message 25 of 28
(2,006 Views)
Hello, all.

Well. I think I have the same (or at least, similar problem than Arthas at the beginning). I am using a wireless inertial sensor 3DM-GX2 with a USB Base Station from Microstrain, and I want to read and use data values from it in LabView. But the problem is that I am not able to use the LabView examples or the SDK provided by Microstrain either. I can't understand what you have discussed here about communication protocols... so as you got to a conclusion, I ask if you can give me basic information so I could fix my problem.

Link for SDK is here:
http://www.microstrain.com/updates/orientation-sdk.zip

I have used the VI called "Read Accel and Ang Rate Serial.vi". I chose the correct COM port for my sensor, that is COM3. When I run, I get the same error that Arthas' in the node "VISA Read" (code -1073807339).

However, I don't know if I have to use this VI because my sensor is a wireless sensor (USB Base Station linked to 3DM-GX2 inertial sensor) and this seems to be a program for reading from a serial sensor.

I am using LabView 8.6.

I hope you can help me. Thanks in advance.

Regards,
Francisco
0 Kudos
Message 26 of 28
(1,829 Views)

Sorry, I forgot.

 

Attached you can see a snapshot of the main program, that you can download from the SDK link.
0 Kudos
Message 27 of 28
(1,820 Views)

Hello,

 

please look also here:

 

http://forums.ni.com/ni/board/message?board.id=170&thread.id=409568

 

Regards Alex

0 Kudos
Message 28 of 28
(1,507 Views)