Showing results for 
Search instead for 
Did you mean: 

Calling DLL Pointer Issues - Read Write BLF

Go to solution

So I wanted to write an API for reading and writing BLF files which are Vector CAN logs.  I contacted Vector and they pointed me to a DLL, some documentation and some demo code.  But I'm a bit stuck and it is probably because of my lack of experience in calling DLLs from LabVIEW but I can't seem to get it to work.


First you call the BLCreateFile function with GENERIC_READ, then call BLPeakObject to see what the header of the next object to be read is.  This works fine.  Then you call the BLReadObjectSecure passing in the header you read from the Peak function.  This also works without an error...but I can't find where my data is that this function read.  The technology fails me but it seems to me that the Read function will write data, to a memory location, that I can't read from within LabVIEW.  Here is some example text on how the demo reads from a text object.


while ( BLPeekObject( hFile, &base))
        case BL_OBJ_TYPE_APP_TEXT:
            /* read text */
            appText.mHeader.mBase = base;
            bSuccess = BLReadObjectSecure( hFile, &appText.mHeader.mBase, sizeof(appText));
            if ( NULL != appText.mText)
                printf( "%s\n", appText.mText);
            /* free memory for the text */
            if( bSuccess) {
              BLFreeObject( hFile, &appText.mHeader.mBase);

I'm confused because all we pass to the read object is the file reference, the base (which is the same data we passed to the Peak), and the size of the object we expect to read.  Then the data is just in the appText.mText object.  But we never passed this object into the function.  How can I perform this same function in LabVIEW?  How can I read from an object that the DLL call modified, but wasn't passed in?


Attached is the C source, the C dll and header files.  The code from above was taken and slightly modified from bl.c.  The Test is the one I'm trying to use to read all messages found in the file.  It correctly finds that there are 3 messages, but I don't know how to read the data.  Similarly I'd like to have the ability to write data and it also seems to eludes me.


EDIT: Okay I think the Move Block could help here (right?).  But where can I get the pointer to base data?  I could then read the number of bytes from there and pass them back to LabVIEW.

0 Kudos
Message 1 of 5

Okay bug found but still not working.  The Read Object Secure structure is a bit larger than I initially made it.  Attached is the replacment VI that has the message, which contains the Header, which also contains the base.  Still the same issue remains.  If I pass it just the base it runs and doesn't crash but I don't know where my data is.  If I pass in the whole message it crashes.

0 Kudos
Message 2 of 5
Accepted by topic author Hooovahh

Try this version. I've made three changes:

- Replaced the mData array with a cluster of 8 elements, since that matches what C does with a fixed-size array

- Type Cast the cluster to a string, then take the string length to get the cluster size, instead of manually adding up all the lengths. This works (but didn't work before) due to replacing the mData array with a cluster.

- Disconnected the "message" cluster from the terminal pane, and connected the (modified) pBase2 instead. Took me quite a while to figure out that the wrong front panel item was connected to that terminal. I couldn't figure out why the data looked right in the subVI but vanished in the caller, and that finally explained it.

Message 3 of 5

Oh thank you so very much.  I clearly need some type def'ing of cluster (why doesn't the wizard do this by the way?) but I was just trying to get something working first then I was going to clean it up.  Besides the prototype issue (that my second post mentioned and fixed) I really just needed the array flattening you mentioned.  I did try to calculate the cluster size with type casting but having the array it didn't allow it, probably because the dimension is an I32 and would cause unexpected sizes anyway.  Thanks again.

0 Kudos
Message 4 of 5

Okay so I was able to write an API for reading and writing BLF files, and I posted it here.

0 Kudos
Message 5 of 5