Chris Cartwright

Hi folks, Does anyone know what happens behind the scenes in the external code call in the "system exec.vi". There is a reference to "systemexec.lsb" file inside the VI that NI used at design time. It appears to call a DLL type function - but where is it? Is it a real DLL somewhere on the PC, or encoded within the vi itself? Any help greatly appreciated! Cheers, Chris.

Thanks Bob, Sure does, I've used this method to interchange data between vi's called from TestStand before, and it's really neat. It's a good way of implementing a "communications manager" (e.g. for serial comms to your device under test), where multiple vi's can talk to it. What I was hoping to achieve was to pass data into TestStand directly from LabView without needing another vi by them using the same queue instance. Having done a bit more research, it can be done, although it seems a little more complex than first impressions suggest. Here's a link to something similar to what I was trying: http://forums.ni.com/ni/board/message?boar...y.id=7658#M5275 Thanks for the info, have sorted my problem through an alternative and simpler method.... Cheers, ChrisC.

Hi folks, Does anyone know of any example TestStand and Labview code that does something similar to the following...? I'd like to start a vi in its own parallel thread from TestStand (which is working), and then at various places through my TestStand sequence, get data back from it via a queue. I've done this between 2 labview vi's on numerous occasions, but I can't seem to work out how TestStand and labview share the queue. Any clues anyone? Cheers, ChrisC.

Hi all, I've got a DLL which I need to call from Labview, which contains a C struct which contains a pointer to an array of another C struct. Is there any way in Labview that I can do this without writing a wrapper DLL over the top to simplify the structures into 2 seperate ones? What seems to be happening is that in the data in "pInput.ConfigPtr[0].Parameter" seems to contain a pointer or labviews own handle, instead of dereferencing it, which is really what I'd expect it to do anyway. Here's the exported DLL function and the C struct definitions for your perusal... extern

Got an update on this one... I've found my original vi written in LabView 6.1 and it also looses its ability to load the CIN under version 7.0. Looks like a change of version is in order. Cheers, Chris.

Hi guys, I'm using LabView 7.0 at the moment and seem to be having a strange issue with the CIN node. If I set a CIN node up to point to my LSB file, everything works fine. Save the vi, run it again, things are still fine. Close LabView, open the VI again and I get a broken run with message "Code Interface Node: object code is not loaded". This is why I'm confused - I've used the exact same lsb/dll files for about 4 years in a similar project written LabView 6.1 and never had this problem. My new vi is written in version 7.0, and has only ever seen this version of LabView, so it seems like it's LabView version related. Does anyone have any clues, other than upgrade to a newer version, as it's probably not on the company agenda - wish I could go back to 6.1 ;o) Thanks in advance... Cheers, Chris.

Thanks guys. I'll give it a go and let you know what happens soon. Cheers, ChrisC.

Hi there everyone, First posting, so here goes... Does anyone know if there's a workaround the normal "Call Library Function" such that you can pass in a path/string to the .dll file you want to call, instead of it being fixed in the Properties page at design time? I've a need to read a customer specific path from a registry key (which I can do no problems), and then call a standard set of functions in a .dll file this the key points to. The function names can be specified at design time in the properies page. The reason behind the required is that there will be a number of these keys all pointing to "different" .dlls. All of which have the same functions/data types, although they do different things going on behind the scenes. Obviously, all of the dll's (should) have been written to the same function/parameter standards, so there should be no problem in interfacing to different copies of the "same" thing. Any help appreciated! Cheers, ChrisC.