From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
08-04-2005 02:28 PM
08-04-2005 11:28 PM
08-05-2005 06:33 AM
08-05-2005 06:55 AM
I have found talking to pointers from labview to be one of the most difficult problems when developing with labview. There is almost always to do it but this problem requires much more work than other issues that arise in labview. Since memory management is shielded from the developer (to some extent) pointers seem foreign to Labview. I have had some trouble when using WIN32 calls which take a pointer to a pointer, usually in the form of an object referenced as a handle which contains a pointer or an array. The only work-around I have found is to write a dll library in c++ which acts as a accessor function, taking the handle to the object and returning a copy of the value stored (or the location of) the data needed. This is time consuming and not all that elegant. I too am interested in similar issues with both .net and c++ interfacing with labview. Sorry if this doesn't answer your question but this discussion topic is of great interest to me.
Paul
08-05-2005 07:14 AM
@Joe Gerhardstein wrote:
...
However, before I can access this record from the C++ portion of the code, I need to type cast the void* pointer to the correct record type (one of 18 types). ... Normally I would use the LabVIEW type cast block,
I don't think I understand your problem. As I understand it, you are getting a void* back from a .NET method (property, whatever), and you then need to pass that off to some C++ code after casting? I assume the C++ code is in DLL? Why the need to cast on the LabVIEW side of things rather than inside the DLL?
Having admitted my lack of comprehension, I will now take a stab and what your problem might be. Perhaps you are trying to cast the pointer and then use it as a C++ object pointer and access member functions or properties? If that is the case, then what you are trying to do requires a C interface DLL wrapper. LabVIEW can't use thiscall calling conventions that would be necessary to directly access the members of the object.
Jason
08-05-2005 07:30 AM
08-05-2005 08:10 AM - edited 08-05-2005 08:10 AM
I don't think I understand your problem. As I understand it, you are
getting a void* back from a .NET method (property, whatever), and you
then need to pass that off to some C++ code after casting? I assume the
C++ code is in DLL? Why the need to cast on the LabVIEW side of things
rather than inside the DLL?
Yes, the C code is in a .dll. This .dll is used as a file
adapter. I can access the file's "directory" via .NET to find the
number and type of records, but actually retrieving the data from the
record (may be milions of data points) is way too slow through
.NET. A record in the file can be one of 18 different types
(single scalar, complex scalar, single 1-D array with evenly spaced
points, single1-D array with unevenly spaced points, complex 1-D array
with evenly spaced points, etc.). This .dll was designed to be
accessed through C++ and .NET (and this is still the vast majority of
its use), so the designer decided just to pass a pointer to the data
and let the actual consumer of the data extract the values (instead of
the code between the file adapter and data consumer having to worry
about the structure), as you would do in a normal object-oriented
language. (It's actually more complicated that this, as the
pointer to the record contains several other pointers that point to the
sub-objects within the record, and each of these need to be cast to the
correct type before consumption as well, etc.) Unfortunatley
during the design of this .dll, it was
assumed LabVIEW would be able to access the structure in the normal C++
way, so this is what I have to work with.
Having admitted my lack of comprehension, I will now take a
stab and what your problem might be.
Perhaps you are trying to cast the pointer and then use it as a C++
object pointer and access member functions or properties? If that is
the case, then what you are trying to do requires a C interface DLL
wrapper. LabVIEW can't use thiscall calling conventions that would be
necessary to directly access the members of the object.
Well, I think you understand what I am trying to do, and are
probably right that some helper-layer is going to need to be
written. Being the sole LabVIEW developer teamed with 40+
C++/.NET developers, I am constantly in the why-can't-LabVIEW-do-that
discussions, so if it can be done in LabVIEW it is just easier to do it
in LabVIEW than spending half the afternoon with the developers and the
project architect discussing it.
Message Edited by Joe Gerhardstein on 08-05-2005 08:15 AM
08-05-2005 08:52 AM
Hi,
Like Paul, this topic also interests me. Here I'll tell about an experiences, hoping that it can bring just an idea.
in one of my last projects, I was using a DLL to capture the data from a miniPLC by using RS232 port. There were some objects like Digital inputs, digital outputs, analog inputs and outputs, function blocks status and etc that I used to read their data cyclically. there was a function in the DLL callled Read_Object and its prototype looked like this:
long Read_Object(unsigned char net_id, unsigned char object, unsigned short int index, unsigned char *data);
See the last parameter in line "data". it seems that "data" is a pointer to a byte. but it was the pointer to the first byte of an array which had different lengths for different objects. I think your problem is something like this. you have a pointer to a point of the memory, but this is the beginning point where a complex data srtucture lies. Is it not possible to feed an array of bytes (with definite length) to the DLL and then interpret the filled array after it has been processed by that DLL? I think there are two major problems with this idea.
1- the whole data will be copied once again in another place in the memory (I am pointing to initialized byte array)
2- interpreting the byte array to our complex data structure may be so difficult.
I hope it can be useful.
I've learned something new in this topic till now. hhmmm, Enjoying!
08-05-2005 08:52 AM
08-05-2005 09:13 AM