DLL Pointer within a Cluster

[j.masse]

To Nathand (et al)

Thanks for your hard work in this matter. I had a similar situation about a DLL pointer to an array of (image) data when using an Artemis camera. I had the hardest time getting the image data but I modified the attached Vi. and it worked very well for me. (I gave this post a Kudo! )

[jrayeske]

Frank,

I just so happen to be revisiting this code to convert a .wdf file to .tdm (or something that I can open in Diadem, since I am failing at the dataplugin).  What I have noticed is the array I am getting back is twice as large as it needs to be.  If my .wdf file contains 50050 points per channel, the output array is 100100 points long (50050 points of correct data followed by 50050 zeros).  The issue seams to be with WdfGetScaleWave64.  Still looking into it more.

Anything change on your end?

Josh

[fdewit]

That's weird. I'm pretty sure I'm getting the proper amount of samples (calculated from the scope settings) from WdfGetScaleWave64, but only half of them contain proper values. I've visually verified that against a saved screen capture of the scope. The rest of the samples come out as 0's, even if you preset the data array with another value. It would seem the zero's are really coming out of WdfGetScaleWave64.

It's slowly getting on my nerves. My Labview just keeps on crashing on this program. Sometimes it even crashes when I press the save button after having done a modification of the code...

Somehow the DLL calls must be corrupting the Labview heap.

I am trying to put together a labview project with a version that works and a crashing one, but even the version Nathan and you provided crashes when using the Yokogawa V3.03 DLL. Unfortunately I can't even open my DL850 WDF files with the old V1107 DLL.

So, deep sigh...

On the up side, I have discovered the location of the documentation for the Labview memory pointer/buffer functions. It is actually in the help file under 'Labview manager functions'. There is also a handy example that shows how your system translates the C variable types. You can find it under the examples: 'Call DLL.vi' under the search keyword 'DLLs'.

I also had a look at the dataplugin development kit, but that seems to be even more involved.

Maybe I will just take the Yokogawa spec and do a quick and dirty data extract, forgo on all the niceties of the WDF format.

Frank

[jrayeske]

Frank,

Figured out why my array was too long.  In the move block, I was inputting the size of the memory, should have been the size of the array.

I attached my code for reading the .wdf that I have had good luck with (infrequent crashing).  Before calling this bit you need to call the 'WdfOpenFileEx' function to create a handle.  I think it is different then what was posted earlier in this thread.  Please let me know if it helps at all.

Josh

[nathand]

Your comments in the code about MoveBlock are incorrect (see the LabVIEW help for MoveBlock) - the size parameter is a number of bytes, not the array size.  I haven't looked at the WDF documentation for the meaning of the BlockSize parameter, but it looks to me like the correct solution to your problem is to remove the multiply by 2 before setting the size of DSNewPtr, then wire the size out from DSNewPtr to the size input of MoveBlock.

If you're concerned about memory use, be more careful with array sizes and numeric representations.  As you have it now, you're allocating twice as large a destination array as necessary, and then only copying data into the first half of it.  You are allocating an array of 16-bit values but copying only that same number of 8-bit values.  You have the call library function node configured to set the array size to the "size" parameter, so the destination array gets cut down to that size, giving you the appearance of the correct result but not fixing it properly.

[jrayeske]

Nathand,

BlockSize = Number of elements in the data array.

If I remove the multiply by 2 (changing it to 1), LabVIEW will crash due to a memory error.  Also, the data returned should be an I16 representation (in the WDF documents) and not I8.  If I change change everything to I8, I also end up with LabVIEW crashing.

Any other thoughts?

Thanks,

Josh

[nathand]

---

@jrayeske wrote:
 

Any other thoughts?

---

Yes.  All you need to do is reconfigure the MoveBlock call so that the minimum size of the output array is NOT set to the "size" parameter.  That's the whole problem.  Sorry I missed that in the first post, despite mentioning it.  The size input is the number of bytes, so when you set your output array of 16-bit values to that size, you get an array twice as large as you wanted.

[jrayeske]

Now I get it, and it even works.  Thanks Nathand.

[fdewit]

Well, it didn't work for me unfortunately...

Is it possible that a memory corruption also corrupts your vi itself, without you being able to see that it is faulty?

At some stage I could recompile my vi and it seemed fine, but it always crashed immediately after starting it. If I then took out blocks to get back to the stage at which the vi really did work fine, it would still crash. Only opening a fresh vi and writing everything from the ground up (or possibly a copy/paste from the original vi, that seems to work too) would make it stable again.

Anyways, I think I have a working version now, at least it seems to work with both Joshes files and all of mine and the code makes sense to me.

I put everything in a small project. If a few people would be kind enough to give it a go and see it it also works for them, I would be grateful.

Thanks,

Frank

[nathand]

---

@fdewit wrote:

Is it possible that a memory corruption also corrupts your vi itself, without you being able to see that it is faulty?

At some stage I could recompile my vi and it seemed fine, but it always crashed immediately after starting it. If I then took out blocks to get back to the stage at which the vi really did work fine, it would still crash. Only opening a fresh vi and writing everything from the ground up (or possibly a copy/paste from the original vi, that seems to work too) would make it stable again.

---

It could happen.  If you accidentally modify a memory location that contains your VI (and it is probably possible to do this if you're not careful about your pointers), LabVIEW might then write that memory out to disk when you save the VI.

I didn't actually run your VI, but I do see that you have the same issue as jrayeske.  In the MoveBlock call, don't set the minimum size of the destination array.  LabVIEW will use the size of the input array as the size of the output array.  Then you can make the destination array an array of U16 and save yourself the typecasting and byte swapping.