Jump to content

NateAtUT

Members
  • Content Count

    2
  • Joined

  • Last visited

Community Reputation

0

About NateAtUT

  • Rank
    I've come back for more.

Profile Information

  • Location
    Nate Kemp

LabVIEW Information

  • Version
    LabVIEW 8.6
  • Since
    2000
  1. Hello, I have a .NET/C# library which was written by a 3rd party. Calling methods in it works perfectly from the LabView development environment (2013, 32bit) when using the .NET constructor and Invoke Nodes. Calling methods in the .NET library also works perfectly when I build my LabView program into an executable and run it without the development environment. HOWEVER, when I build the LabView program's functionality into a .dll instead, and then call functions in this Labview-built .dll via a CLFN instance in a higher-level VI, the underlying functionality of the .NET library doesn't work and the development environment subsequently hard-crashes and must be restarted. ARGH!! Any thoughts why this might be happening? I've had no problems calling non-LabView C++ .dlls inside of LabView .dlls, but calling C# .dlls inside of LabView .dlls appears to be a no-go for me right now. Am I missing a compiler setting or is this basic paradigm just not possible? Or is it a known bug with LabView. Thanks, Nate
  2. Does anyone have an example of a hierarchical state machine programmed with the same level of detail as the flat state machine examples provided here already? I'm sure that LabHSM is great for achieving fast and robust HSM programs, but it's a closed design and difficult to interpret what is going on "under the hood". For illustrative / educational purposes, something with nested case structures and shift registers might be better. Thanks, Nate
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.