scorn001 wrote:Also, Console.Write does work and produces output in the Read loop.
So this must mean Console.Write uses another StdOut then the printf in the dll?
↧
Re: Capturing STOUT/STDERR from C DLLs
↧
Re: Capturing STOUT/STDERR from C DLLs
rolfk wrote:
wiebe@CARYA wrote:The dll fails to load:
LabVIEW: Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format.
You don't have the Visual C Runtime redistributable files installed that correspond the the Visual Studio version that was used to create the DLL!
Figured as much. My post crossed your.
↧
↧
Re: Capturing STOUT/STDERR from C DLLs
BTW. I checked Console.Write with an AllocConsole (use FreeConsole to remove this window).
Using Console.Write does output to this console. (You do need a restart if you redirected the StdOut.).
Can you check if your dll outputs to a fresh AllocConsole window?
↧
Re: Critique my loop to send a text file, line by line or en masse?
Critiquing in general, I'd say that you need to learn dataflow basics. From a cursory look at your block diagram, I'd say all of your sequence structures could be eliminated with a proper understanding of dataflow. (And if proper use of local variables was observed.)
This will free up LabVIEW to execute nodes in the order it sees fit to execute them. This is roughly analogous to letting the operating system decide which thread to run next instead of dictating the order yourself.
↧
Re: Capturing STOUT/STDERR from C DLLs
wiebe@CARYA wrote:
scorn001 wrote:Also, Console.Write does work and produces output in the Read loop.
So this must mean Console.Write uses another StdOut then the printf in the dll?
Absolutely!
That are the _open_osfhandle() and _fdopen() calls in the C code example. And if you happen to compile your C++ code with the cpp compiler you also need to add a call to ios::sync_with_stdio() after you mapped the C runtime stdio fds to the process stdio handles otherwise the C++ template printf routines end up sending their stuff to the old stdio fd (which might be invalid because the LabVIEW process was started up without console).
And here you basically run very likely into the problem that it simply can't be done outside of the actual DLL that wants to do redirection. As soon as you write a second DLL to do all this stuff it will link with a particular C runtime library (either dynamically or statically if you setup the project to include the C runtime in the DLL) and if your DLL was created with a different Visual C version than the DLL you want the redirection to work in they will link to different C runtime libraries that know nothing about the stdio redirection in the other one if both DLLs are set to link dynamically to the C runtime. If one of them is set to link to the static C runtime version they will use their own separate view of the stdio fds and then it fails anyhow.
↧
↧
Re: Use the PXI-4071 DMM's Digitizer to collect discharge voltage
Have you downloaded and installed the NI-DMM driver? They are included with the driver, as well as the Fetch & Graph Waveform.vi example shown in the previous screenshot.
NI-DMM driver link:
http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/sn/ssnav:drv/q/DMM/
↧
Updating Malleable VIs
I have been using a Malleable VI in an FPGA Project I have for some time now. I recently discovered a way to achieve the same functionality with reduced resource utilisation.
If I update the *.vim with the new code, will my next compile automatically include the new method? I ask because when placing the malleable VI initially, it is inlined and I got the impression that my VI containing the malleable VI only gets marked as modified if I right-click on the VI and view the generated code......
So can anyone chime in with an idea whether such an update of the malleable VI is automatic or not? Especially in an FPGA context.
↧
Re: Capturing STOUT/STDERR from C DLLs
I thought "A DLL doesn't have a stdin/stdout/stderr in itself. it inherits the stdin/stdout/stderr of whatever process the DLL is called from. ".
So shouldn't Console.Write in LV output to the same StdOut as the DLL running in LV?
Maybe the redirect needs to happen before the DLL is loaded?
↧
Re: Capturing STOUT/STDERR from C DLLs
This seems to be happening:
https://stackoverflow.com/questions/17323299/redirect-stdout-from-loaded-dll
No solution...
↧
↧
Re: Projectile motion
I don't have the Matlab Toolkit, so I can't run your code.
Maybe you have to convert from degree to radians before feeding it into the sinus or cosinus function?
I hastly translated your script in plain Labview G code, this is what I get:
↧
Re: Jumping Mouse in LabVIEW with Laptop
We have also seen this behavior on Dell Latitude E7470s. Both my laptop and a coworkers exhibit this behavior and they were fresh laptops with fresh installs of Labview 2014 and Windows 7. I've tried disabling touchpads and touchscreens and see no change. The mouse behaves normally for all other applications.
↧
Re: Projectile motion
You're on the right track. I made the changes directly in the MATLAB node and while not familiar with the expressions used, produces a reasonable trace.
With such simple functions, the Mathscript node (if available), or even the formula node could be used instead.
↧
Re: Capturing STOUT/STDERR from C DLLs
Again, very good information. Thank you rolfk.
So it sounds like maybe I will need to build the dll with the redirect code built in using a wrapper maybe.
↧
↧
purchased educational version but only get option to download trial version...
I purchased the full version of Labview. Have receipt and under downloads there is a link. But it takes me to a screen with only two options: "download trial development system" which it wouldn't do
and
other option is "have labview development system already"
which obviously I don't have... ??? Did I get ripped off?
↧
Re: Capturing STOUT/STDERR from C DLLs
I think the DLL itself can redirect it's outputs (to a named pipe). So I think you could make a function that set's up the redirection. Then, the rest of the dll could stay the same?
↧
Re: Capturing STOUT/STDERR from C DLLs
wiebe@CARYA wrote:I thought "A DLL doesn't have a stdin/stdout/stderr in itself. it inherits the stdin/stdout/stderr of whatever process the DLL is called from. ".
So shouldn't Console.Write in LV output to the same StdOut as the DLL running in LV?
Maybe the redirect needs to happen before the DLL is loaded?
Well it doesn't have it's own console since a process only can have zero or one console at any time. But the Standard C library uses internally file descriptors everywhere, which is basically an integer enumerating all the opened streams in the C runtime library. When a DLL is started up it also internally calls numerous routines that initialize the C runtime library and one of them associates the stdio fd's with the actual console stdio handles (and if they are invalid it maps them to an fd that is analogous to the famous /dev/nul device).
So it doesn't have its own stdio but it does require a separate mapping of stdio fd's to the actual console stdio handles, which are normal Windows stream handles.
↧
Re: Capturing STOUT/STDERR from C DLLs
wiebe@CARYA wrote:I think the DLL itself can redirect it's outputs (to a named pipe). So I think you could make a function that set's up the redirection. Then, the rest of the dll could stay the same?
The redirect won't need to re-setup each time I call into the DLL? I'd assumed that it would. I'll test that.
↧
↧
Re: i2c on myRIO-1900
I had similar problem at using I2C LCD module(ACM1602), but solved.
by connecting 'True' into 'Keep bus BUSY' at low-level function 'Write.vi'
↧
Re: purchased educational version but only get option to download trial version...
Similar to other versions, you should be able to download, install with your serial number (or by logging into your NI.com account) and have the version you paid for.
↧
Re: purchased educational version but only get option to download trial version...
You probably did not get ripped off if you bought it through NI or another reputable source. The trial version will be the exact same as the real version, except it expires after some time. So once you install LabVIEW, you just put in your license and it will become the "student version".
↧