View Single Post
  #2   Spotlight this post!  
Unread 07-02-2009, 09:21
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,751
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: Calling C/C++ from LabVIEW

If all that seems daunting, feel free to describe the higher order stuff that you are finding difficult to do in LV. Pretty sure I can help if you'd rather go that direction.

The other things I'll mention about hooking C code to LV is that you need to watch carefully what the parameter types are. It is obvious, but since LV has to trust what you tell it about the types, it is rather blind. If you don't get the number of dereferences correct, either the C code will crash, or LV will crash when it returns to find its memory corrupted. Also, be careful about ownership of buffers. It is possible for the DLL to reallocate the LV arrays, but only if you know the implementation of the LV arrays. Don't assume you can just realloc them, or assume they are vectors, they aren't. It is far better to keep the allocation and resizing and cleanup of a piece in the same component. So, allocate, resize, and free on the diagram only letting the C code read the data, OR do all of these in C and make LV treat the buffer as an opaque type.

If you need knowledge of LV types, alignment, etc, look for the appendix that goes into those details, and of course ask lots of questions.

Greg McKaskle