02-20-2020 02:21 PM
Link to C++ library.
http://docs.ros.org/lunar/api/sbg_driver/html/files.html
Use that to emulate using LabVIEW functions.
02-20-2020 02:45 PM - edited 02-20-2020 02:50 PM
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.
02-25-2020 09:00 AM
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.
03-05-2020 10:27 AM
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.
03-05-2020 02:37 PM
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.
03-09-2020 11:38 AM
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.
03-09-2020 11:45 AM
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.
03-09-2020 03:00 PM
going to go ahead and try that now. thanks.
04-19-2021 03:50 AM
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