Occationally when I open my Main.vi in LV2015SP1 I receive the following error:
Kithara Software, Error in PROCESS ATTACH (Unknown Operating System)! (Error=0x10070000).
This could simply be an issue with my computer (Windows 10 Pro, 64-bit) but I just find it odd that I only see this error when loading my main vi. Any ideas as to why this is occurring? Does
Thanks,
Craig
I presented on TDMS at NI Week 2016, here is the content, sorry no video. I think what you will find is that TDMS can be a large topic. There's plenty of things to avoid (like unnecessary writes), but doing these things won't generally break things, it just might result in a poor experience, or you might not even notice. The design and structure is up to you and that might be one place where people make mistakes since they don't really know what works and what doesn't when they first try it out. If you have N devices should you have N TDMS files? or N groups in a single TDMS file? Or just all the data in one group? What properties should I write to the channel? Group? File? These all depend on the application and I can make suggestions based on a design but until you use it for a little while generating data, and seeing how the other users consume that data, you won't know if the design was a good one. Sorry for such a long answer when I could have just said "It's up to you".
thanks for your help!!! Thank you!!
ATE-EGNE wrote:I like the use of the NOR gate (wouldn't have thought of that)
It is actually an XOR (exclusive OR). A XOR TRUE = NOT(A)
Hi
Where did you get the Labview VI's for the PXI 4071 multi-meter because i tried opening up your vi and it couldn't find "niDMM Fetching Waveform.vi" did you make those yourself? my email is Intern@wascoinc.com if you need it
thanks
Devin
Thanks for the code. let us try it
Did you try to use the Execution Highlighting, the probe watch, and the breakpoint manager ?
Hi sjacksonPA,
Did you see the button that had that icon or one similar to is on the page after logging in to the compile server?
It might be a little subtle but I believe it should be there on the login page.
David
Yes, I am using an XOR (you could also just use a "not equal" 
). You replaced it with a "not XOR" for some unknown reason. Notice the little circle on the output of yours!
What is "Kithara" software?
I don't think that has anything to do with NI or LabVIEW.
Dear all,
As titled, my laptop having high CPU usage when grabing image using the IMAQdx. I had attached my front panel image and program for your reference. I found that the CPU consume high usage for USB camera only as no high CPU usage if i am using my laptop integrated camera. Besides, i tried to grab the image in NI-MAX software, the usage is around 30%. I had searched the NI forum and tried to install the NI-IMAQ for USB driver as forum members told but still no improvement on the CPU usage. I need to solve this because i have to connect to 4 cameras in an application and the usage is accumulative with number of camera. My laptop just hang if i connected to 3 and above cameras simultaneously. I am appreciate if you can guide me for furher troubleshooting method.
I hoped the header files wouldn't be necessary in order to identify "resource" related syntax with the potential to "stomp" on neighboring process memory. "myVendor.h" does #define the initial DAQ buffer-size constant, but DAQ buffer is reallocated later, prior to DAQ, based on finite-DAQ size.
Yes - the "ID" parameter allows the DLL to identify, and communicate with, a specific "drive". I created two EXEs - one for each DLL/copy (each communicating with a different "ID") - they run in parallel without errors and without interfering with each other. This ID mechanism can even work when the two copies of the DLL are loaded by LabVIEW IDE. Today the two DLLs ran in parallel for about 4 hours without error. The application terminated normally, but the access-error appeared on restart - even with non-reentrant FP opened/hidden (1st time).
Unfortunately, obtaining help/information from the "external party" is not convenient.
It seems it's time to start "carving out" a test case!
I need to read a text file containing a command script and send it, line by line, to the input function of a DLL, then read back the response from the output function of the same DLL. I wanted the option to send it one line at a time, for debugging purposes, or all at once, for speed (it might be 6,000+ lines). After reading many examples and not really understanding state machines very well, I arrived at the following solution:
It works, but it seems inelegant, especially the initialization and incrementing. Should I have used some sort of auto-indexing? Or is it really not that bad?
Thanks!
Attached is the dll and the source .cpp file. There are a few other routines in there as I've been tinkering a bit. The goal is to have the "printstuff" - which only has a printf and a return, work - without any of the redirect stuff in the other routines.
I haven't attempted the Console.WriteLine. I expect it will work, but I'll give it a try just to be sure.
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.
These Attributes can be set and retrieved with the kernel32.dll.GetFileAttributes() and kernel32.dll.SetFileAttributes() APIs very easily. That is not the problem, and password protecting such a VI is quite overkill!
The earlier poster wanted to change other things of a file such as comment, description etc. and that are not properties handled through the Windows API but by the shell (File Explorer) and stored in NTFS streams in a property handler private format.
The property handlers for any specific file type are implemented as COM objects and invoking them is only possible from C/C++ code. So someone would need to write a DLL that does the enumeration of the property handlers for a particular file type, then invoking them all to enumerate the properties each of them supports for that file and invoking them again to retrieve and/or change the property value for each of them. This DLL then can be called from LabVIEW to do the nitty gritty stuff of communicating to the shell property handlers and return the interesting stuff to the caller.
More easy would be probably to use something like https://filemeta.codeplex.com/ and using their command line tool through System Exec, retrieve the desired informations from a file and make modifications to the metadata of said file. Note however that this metadata is not stored directly in the file and associated with the file through the File Explorer shell. As long as you move or copy a file through File Explorer the association is maintained but if you do this through another application such as a LabVIEW File Move, there is a good chance that the association is lost and therefore the file looses all the properties. They get definitely lost if you email a file or transfer it to a non NTFS media such as FAT32 formated USB disk.
I really appreciate you putting in all this effort to help me with this. If I haven't said thank you before - thank you.
I rebuilt, removing all of the other unused routines. This should just contain a single printstuff routine.
Also, Console.Write does work and produces output in the Read loop.
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! And this actually listens very closely, if you happen to have Visual C runtime V 16.00.29023 installed but the DLL was compiled in Visual Studio with Visual C runtime updated to 16.00.30319 then you are likely getting such an error.
scorn001 wrote:I really appreciate you putting in all this effort to help me with this. If I haven't said thank you before - thank you.
You're welcome. The reason I (and Rolfk I presume) help you on this one, is that is getting this to work is useful for us too.
scorn001 wrote:I rebuilt, removing all of the other unused routines. This should just contain a single printstuff routine.
The dll still gives the same error (with dynamic path). I think I need a C runtime or something.
