Copy untyped void * buffer over LabView struct equivalent

[Deutschrich]

I already tested to define an array that later will be called from Labview. The problem was the same, also I receive only data on the fist line of the array and on the others nothing....

[rolfk]

---

@Deutschrich wrote:

I tested the same code with debug on the console of visual studio. MiBuffer had all the data and I could show them on the console.

I say, The only thing what I changed of my code is the declaration of variables those I need on Labview. Instead of showing the variables (elements of my buffer) on console I save now each element in a variable which will be called on Labview.

Now I don't know how I can check from my debugger while Labview is running...

How can check it?

thanks

---

Well, obviously there must be a difference between your console test program and your LabVIEW test program that causes this issue. The only way I can see the other variables to be 0 is because Scara->Read() does either fill them in that way or leaves them at their default value as initialized by the gcnew function.

And the best way to confirm that is using a source code debugger and go and look at your MiBuffer array after the Scara->Read() call. If this shows only the first value to be filled in you will have to look for the reason that your Scara->Read() function only returns that, otherwise I'm going to get my crystal ball working and do get the big book of magic, as there is no obvious and explainable reason so far why the Scara->Read() function would fill in those data in the array but your C code doesn't copy them into the LabVIEW variables.

I'm correct that this is C++ code and not something like C#? Some of the naming conventions look much more like C# but they may be recent additions by MS to C++ to match closer with C#. If it is C# all bets are off. I have no idea how to do an unmanaged DLL in C#.

[nathand]

Just to confirm... if you use cout to display the variables that you will pass to LabVIEW (RBuff00, etc instead of MiBuffer), does all the data show up properly?

As Rolf suggested the best thing to do would be to attach the C++ debugger to your DLL so that you can debug as you call it from LabVIEW, but I can't offer any instruction on how to do that.

[rolfk]

---

@nathand wrote:

As Rolf suggested the best thing to do would be to attach the C++ debugger to your DLL so that you can debug as you call it from LabVIEW, but I can't offer any instruction on how to do that.

---

I was about to write a lengthy explanation but someone else has done it already for Visual C++ here. For other compilers you would have to read the online documentation for that compiler to see how to attach the debugger to an already running process.

[nathand]

You might try changing the calling convention (stdcall or winapi) and see if that makes a difference.

[Deutschrich]

Hi nathand and Rolfk,

Thanks for your replies.

Here I attach again the c++ codes. The first is of my Win32 Console Application that ran well and show me my buffer. I attach too an image of the console where you can see how my buffer is showed. The second is the c++ code I changed to make a DLL for Labview. So now you can see that the code didn't change much. I just assign a variable pointers to each line of the buffer.

Thnaks for your help

[Thør]

Did you try attaching the C++ debugger that was suggested a few posts ago?  If so, did this give you any errors?  Also changing the calling convention is often a very simple way of fixing strange dll errors.

[Deutschrich]

Hi Kyle,

I already ran the debbug and in fact I receive only data in the first line of the buffer. I don´t know why it occur because when I made the program on the console, also no dll, the console shown all my data so the 18 line of my buffer, but when I made the Dll and I call it from LabVIEW, LabVIEW in my front panel show me only the fist, or the first with the second line of my buffer. I find that I changed almost nothing of my first c++ code to dll.

You can say me why it occur and how can see my full buffer from LabVIEW?

Cheers,

Ricardo. 

[rolfk]

I for one can't! The only way I could MAYBE say something at this point is by running it myself with source level debugging but you will understand that this is a bit much for free consulting services.