How can I call subVI(s) inside a CIN (Code Interface Code) ?

[smercurio_fc]

If you don't want to do graphical programming then you shouldn't be using LabVIEW.

LabVIEW provides an ActiveX interface but it's not intended or designed to be used to create LabVIEW programs. LabVIEW has its own scripting interface, but you have to (a) pay for it, and (b) program it in LabVIEW. You could use the ActiveX interface to call the scripting engine but that seems to be like trying to swat a fly with a sledgehammer.

It seems that you're asking/talking about something completely different than what you started with. Perhaps LabVIEW isn't the best platform for what you're doing or trying to do...

[Dennis_Knutson]

I agree and think your question is confusing. What kind of 'API' does C++, .net. VB, whatever, provide to tcl? A LabVIEW program can be made into an exe or dll. A LabVIEW program has an ActiveX interface and you can access it's properties and methods. If you can call an exe, a dll, or use ActiveX with a text based scripting language, then go for it.

[tbd]

Hi cemal,

      Wow, looks like this thread has taken a strange turn.  Having spent a day building a CIN, it now looks like an answer to your original question is irrelevant!

Well, similar questions have been asked before; if you're still interested in "How can I call subVI(s) inside a CIN (Code Interface Code)"

the attached .zip contains a LabVIEW 8.2 MyLVDLL project, and a VC++ 6.0 Workspace that will build a CIN (it builds the .lsb file.)

The top-level MyCIN.vi passes a VI path to the CIN which calls MyLVDLL to open the VI.

Cheers!

Message Edited by tbd on 02-21-2008 10:07 PM

[silicomancer]

Hi smercurio_fc!

That scripting interface your are mentioning... it makes me very courious...

How is it called?

Where can I find information about it?

What is it able to do?

What does it cost?

Is it some kind of extension/plug-in of LabView?

Which scripting language does it use?

Thanks in advance for any answer to my questions!

[silicomancer]

Hallo tbd,

I had a look on your example. I wonder where did you take the labview.lib and lvsb.lib from? And where did you find that extcode.h header? They seem to be part of some kind of SDK!? What exactly do these libs do? Are they documented somewhere?

[silicomancer]

---

Dennis Knutson wrote:
I agree and think your question is confusing. What kind of 'API' does C++, .net. VB, whatever, provide to tcl? A LabVIEW program can be made into an exe or dll. A LabVIEW program has an ActiveX interface and you can access it's properties and methods. If you can call an exe, a dll, or use ActiveX with a text based scripting language, then go for it.

---

Hm. LabView isn't comparable to text based programming languages, is it?

For example: One could intend to execute graphically developed VIs from a text based script directly... WITHOUT converting them to a DLL or exe first?

Or maybe on would like to use LabView's hardware drivers in his scripts?

How would you achieve this?

[Dennis_Knutson]

LabVIEW is a full featured programming language and is comparable to other programming languages in terms of functions, execution speed, etc. Whatever difficiencies, are made up in that it is easier to write programs with, imho.

As already said, you have the ability to use VI Server/ActiveX to control a LabVIEW VI. There are examples available for c and vb programs on how to use the properties and methods of a VI. This does not require that you build a VI into an exe or dll but it would require you to have the LabVIEW programming environment installed.

LabVIEW does not have hardware drivers. LabVIEW uses hardware dirvers. It uses the same hardware drivers that developers in c, vb, .net, etc. use. I have seen tcl scripts that use NI GPIB calls and suppose that the same is possible with DAQ. Certainly you could write a LabVIEW VI to call those drivers and then call the VI from another program but if you are an accomplished programmer in the other language, why bother?

There also seesm to be some confusion on the use a a CIN and what scripting is. A CIN is a type of dll that you create with something like Visual Studio. It used to be the only way that you could integrate c code into a LabVIEW VI. Since NI introduced the Call Library Function Node that can access any dll, there is very little need for a CIN. A CIN has no relationship to a scripting language such as tcl other than that both require you to use a keyboard.

When you see the term 'LabVIEW Scripting' on this and other forums, what is being talked about is a way to generate LabVIEW code from another LabVIEW program. It is not a simple task or generally available.

[tbd]

---

silicomancer wrote:

... I wonder where did you take the labview.lib and lvsb.lib from? And where did you find that extcode.h header? They seem to be part of some kind of SDK!? What exactly do these libs do? Are they documented somewhere?

---

The resource-files you mentioned are all installed with LabVIEW and (by default) located in:

<root>\Program Files\National Instruments\LabVIEW x,x\cintools

Here are some instructions related to use of these files.

Cheers!

[silicomancer]

Thanks Dennis, for your reply.

So if one wants a script to be able to do anyhting a graphical LabView program can do, the solution is to control the VI server directly, right?

[silicomancer]

---

tbd wrote:

The resource-files you mentioned are all installed with LabVIEW and (by default) located in:

\Program Files\National Instruments\LabVIEW x,x\cintools

Here are some instructions related to use of these files.

Cheers!

---

Ok, thank you very much!