LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Device is not responding to commands

Solved!
Go to solution

Link to C++ library.

 

http://docs.ros.org/lunar/api/sbg_driver/html/files.html

 

Use that to emulate using LabVIEW functions.

Tim
GHSP
Message 11 of 19
(1,112 Views)
Solution
Accepted by topic author arosss

Phew... You're dealing with a high-level message-based binary protocol, which you don't seem to understand. The documentation you posted is incomplete, so I have to guess a bit. For example, it's not clear whether the device will spit out data right from the start at a certain rate or whether it's a request-reply kind of thing.

 

In any case, all communication seems to happen in "frames" on top of the physical layer (RS232, CAN, ethernet) and you have to send requests and parse replies in exactly this format. The serial setup seems to be configurable through messages and I hope you got the initial/default setup right (9.6kbaud/s etc.). The termination char should not be used (as mentioned before), since you're dealing with potentially arbitrary binary payload. Therefore, you have to write a "smart" read routine, which reads the header of a frame (fixed number of bytes) and then reads the rest of the frame based on the "length" field. Then you have to unflatten the data based on the message ID/class or whatever the documentation says. The same is true for sending commands: arrange your "payload" inside the frame (represented as a cluster) according to the documentation, which includes calculating a CRC16 (that's fun :)), and then flatten everything to string with little-endian format and write it to the port.

 

You will need to make a minimal "library" for parsing and assembling the data in the right format for the protocol (it might potentially all fit in a case structure that is disambiguated by the message ID) before you can have any useful communication.The protocol seems too complex to quickly "botch something together" just to get it to work, but it will be a nice exercise in using typedefs and hierarchical data structures :)...

 

Edit: The link above is a complete implementation of the protocol in C, including variations of the hardware model and interface. You only need to implement a small subset of this for your application.

Message 12 of 19
(1,093 Views)

So, if I'm understanding you correctly. Say I want to send the SBGEComBinaryLogUTC.c file to the device. What I would have to do is basically read the C code as a sort of pseudocode and do my best to put it in a LABView VI, save it as a DLL and then use the Call Library function in my other, VISA VI, before finally writing the output to the device, of course assuming that I 'frame' it correctly. 

 

I have tried just opening the file and writing it to the device before I realized that it must be compiled. I apologize if these questions seem silly, I am new to binary protocol and this is the only device that I have worked with that is so resistant to Labview. 

0 Kudos
Message 13 of 19
(1,032 Views)

Hey! The reply comes late because I didn't get a notification...

 

The .c files from the SDK library are not to be sent "to the device"! This is not an Arduino or the like where you write/compile your own firmware. The device already has a (proprietary) firmware, which you're not supposed to change, except maybe for firmware updates following the respective instructions. All that C code is to help you make an application that runs on your PC (or other platforms) and communicates with the device over the serial port. "All" that's needed to communicate with the device is to send the correct commands over the serial port and interpret the replies; the device should be already working out of the box when powered on.

 

If you compile the C code (and know what you're doing), it should result in a simple application for Windows or whatever OS you're using to communicate with the device. I haven't looked into it, so I can't tell if it comes with a sample GUI or if it's purely a library. In any case, if you want to make your own implementation in Labview, you don't need the C code, you only need the exact protocol specs from the data sheet and implement them yourself from scratch in Labview. The C code can be helpful to understand how the specs are supposed to be implemented in "real life" and it may make it easier to recreate those subroutines in Labview.

 

Alternatively, you can let the C code do the entire communication and just provide a high-level API (i.e. function calls) for Labview to query the actual data. Then you need to compile the C code into a DLL and call the relevant functions through Labview. In that case you won't need the VISA stuff at all and the Labview part would be more or less trivial, but you essentially would have to make an entire C program (as a DLL) to do the communication using the SDK code. Either way will work and you should choose the one you're more experienced/confident with.

Message 14 of 19
(1,008 Views)

Thanks for your time in replying. I appreciate it. I realized that was a dumb question later that day. I've figured it out for the most part. Thanks again for all your help. Have a great day. 

0 Kudos
Message 15 of 19
(989 Views)

So I've attached the firmware manual along with my Project. I keep getting an overrun error in the read data size VI. Even when I try to read just one single byte of data. What my program is doing, is setting up the serial port, then it is sending a Message ID of 0x02 (see page 58) to specify that I want the UTC log data, the message class is 0x00 because it is a LOG cmd. (see pg. 17 for that Class ID information). 

 

Next, when using a transfer command initialize (0x0000) the device should message me back as seen on page 21 with repeating of the TransferCmd, then the size of the data to be transferred. I then try to read that number and use it in the payload of the initiation transfer command. 

 

I have attached boththe firmware manual and my project if someone could please offer a suggestion of what might be going wrong that would be awesome. 

0 Kudos
Message 16 of 19
(957 Views)

Check to make sure your firewall is allowing coms. You could try turning it off and see if that fixes the problem. I have seen this problem before and it was the firewall for me.

Tim
GHSP
Message 17 of 19
(950 Views)

going to go ahead and try that now. thanks. 

0 Kudos
Message 18 of 19
(932 Views)

Hi together,

I recently got an Ellipse 2 Sensor from SBG and also want to implement the data to an existing Labview data acquisition program. Thus, I would be interested if you succeeded with your Micro Ellipse? Any response would be highly appreciated. Thanks a lot, and best regards, Benny

 

0 Kudos
Message 19 of 19
(825 Views)