Call Library Node + Windows Console

[ACiDuser]

Hello NI developers!

I have a DLL for LabView.

Inside the DLL there are many "printf("...Text....")" calls.

If I compile source code as an .exe and run it - it runs a windows console and shows text outputted buy " printf(....) " and even somewhere expects input from keyboard.

I want my DLL, when I execute VI, also launch console and show all the information the same way as a console application.

I understand that I can simply make a VI which executes .exe application, but I need to receive data from this program to Labview, so I think I should use a DLL.

Could anybody point me at a possible solution of this problem?

Thank you in advance.

[Andrey_Dmitriev]

Hmmm.... Console LabVIEW application?

I mean, you can organize your SubVIs to DLL, then call these LabVIEW DLLs from small console application.

Something laike that:

Console App.exe <- LabVIEW DLL <- your DLLs with (printf)

Just suggestion...

Andrey.

[ACiDuser]

no no,

I have dll for example:

_declspec(dllexport) void LVMainFunction(...)

{

    Function1(...)

}

 Function1(...)

{

    Printf(" TEXT ");

    Function2(...);

}

Function2(,,,)

{

   Printf(" TEXT ");

   Function3(...);

}

Function3(...)

{

   Printf(" TEXT ");

   Function4(...);

}

.....

.....

I want to see Printf output in a console which opens when I launch VI.

I mean to use something like    AllocConsole(void)

But this is a WINAPI function what should I include to use this type functions?

 Regards

Message Edited by ACiDuser on 11-07-2008 05:35 AM

[Andrey_Dmitriev]

Ah, so,

now understand... Read here a little bit for getting started: http://support.microsoft.com/kb/105305/en-us

regards,

Andrey.

[Wiebe@CARYA]

The reason DLL's don't use printf to write to consoles is that this is very
impractical.

A command line application allocates it's own console by default, but a dll
doesn't. This doesn't mean it's not possible, but it will be very
complicated. The calling process needs to create a console. This console
reference (or something) needs to be set by an init function in the dll, so
all the functions use it. AllocConsole, AttachConsole, SetStdConsole and a
few others seem to be applicable. An aditional problem will be that the
console of a process is probably a global thing, so setting the console in
the dll will also set this console to LabVIEW.exe....

Why not use ogPipes? You can open the command line application, and write to
and read from it as you please (without closing the command line
application). That seems a lot easier.

Regards,

Wiebe.

[chrisger]

hi there

if you don't want to change the DLL you could create a C/C++ Wrapper console application that calls the DLL functions. You may pass the exe the path to the dll, the functions name and the functions parameters to call the DLLs function with LoadLibrary (this would be a complete generic approach).

Then use "System Exec.vi" to call the console application and fetch the console output from the "standard output" indicator of "System Exec.vi". You even can pass console input to the "Standard input" control of "System Exec.vi" (but the handling would be different than that of the console application).

[ACiDuser]

to Wiebe

I've already tested AllocConsole(). It opens a console and attaches it to VI's process. So if I close either the console or VI - both of them closes immediately.

I even learned how to print text in a new console. But I reached a problem that my driver uses a custom function which processes inputs from a keyboard. 

And it is quite difficult to edit this function. So this solution is rather complicated.

Could you tell a bit more about those "ogPipes" ? or post a link to a some kind of doc.

And what If I do not want to run my VI from a Console by typing every time? Then I could make two VI's, 1st VI simply launches command line and runs 2nd VI, which does all work.

[ACiDuser]

to chrisger:

I problem is that I want to implement data acquisition between DLL and VI in real time. If i call with a System Exec a wrapper console application, VI is connected with Console App.. Console App is connected with DLL.

It means that I will be able only print data to file, and then with VI read it. This will dramaticaly reducre performance of my driver. (I think so)

But I still need to recevice data from DLL in array format.

How can I solve this?

Maybe running a VI from a command line could be a better way?

[ACiDuser]

Can't install OpenG library cause my LabView's version is 7.0

[ACiDuser]

Ok. I set up LabView 8.2.1 run-time engine and installed VIPM, but in a list of available packages I don't see oglib_pipe. Is this library still in alpha stage?