Mark Smith

Use the C String Pointer type in the Call Library Function for the LPSTR type (long pointer to string, where long means 32 bits - leftover from 16-bit Windows!) and the same type with the Constant box checked for LPCSTR (long pointer to constant string). Mark

Yair, I think you're probably correct that as you open the front panel it will take focus but if you leave it open and then don't invoke the "Show Front Panel when Called" method I don't think it will take focus on subsequent calls. So once the sub VI is open the user can bring the main VI to the top and it will stay there. I can't try this right now and confirm this to be true (since I'm not at a computer with LabVIEW) but I think this is correct. Mark QUOTE (Yair @ Nov 29 2008, 09:14 AM)

I don't think that key focus is the right thing to consider here - what I think is happening is that you probably have "Show Front Panel When Called" enabled in the sub VI or in the SubVI Node Setup, so all LabVIEW knows to do is switch the panel (window) focus to that sub VI whenever your main routine calls it. As soon as that happens, the Main VI is in the background. You might want to dynamically open the subVI panel (don't enable "Show Front Panel When Called" in the sub VI or the SubVI Node Setup) and then when you execute the sub VI it will show its current data but it won't bring the panel to the front or cause a control in use on the main panel to lose focus. Mark

Every time I've encountered this error message "Error loading "C:\blah_blah_debug.dll". This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem." It has been when a DLL was built with the debug switch on and is linking to the debug version of a Microsoft run-time DLL. In your case, you're probably using msvcrtd.lib which links to the msvcrXXd.dll, where XX is the version (80 is typical). The msvcrXXd.dll is not part of the standard windows install where the msvcrXX.dll, which is linked to by the msvcrt.lib, is - that's why the release version runs and the debug doesn't. Make sure you're not using a /MDd compiler switch (the default release build does not but the Debug build does). I've found this app http://www.dependencywalker.com/ to be pretty useful in discovering which run-time component is missing when a DLL won't load. As far as "Error 13 occurred at dll_name.dll Possible reason(s) LabVIEW: File is not a resource file" I don't know - I don't have any experience with this error message in the context of loading a dll - I have seen it in other circumstances but none seem related to your case. Mark

The TCP IPv6 Toolkit in the Code Repository has been updated to support Buffered and CRLF modes in the TCPIPv6_Read.vi. The original toolkit only supported Immediate and Standard modes. Mark

Build your LabVIEW VI as a DLL and then call it from C++ - see these links http://zone.ni.com/devzone/cda/tut/p/id/2719 http://zone.ni.com/devzone/cda/epd/p/id/1515 Or, if you're using managed code in VisualC++, check out http://zone.ni.com/devzone/cda/epd/p/id/6050 Mark

OK, now this is getting complicated - probably beyond my ability to help! I assume that when you looked at the dependencies of the DLL in question, it pointed to the folder in your \WINDOWS\SxS directory (that's the Windows Side-by-side directory). I'm not very familiar with that but a little quick reading indicates that it's a place that COM DLLs can live "side-by-side". Evidently, XP and Vista can use "Registration-Free COM" activation and when this happens COM DLLs get installed in the SxS directory, along with a manifest and a "security catalog". This means that the COM object doesn't get entered into the system registry - rather, at run time the calling application (the EXE) now must reference a manifest file (typically in the calling EXE's directory, as far as I can tell) that contains information about how to load files from the SxS directory. Since you had a system that worked when VS 2008 was installed, the manifest information must have been somewhere in the 2008 hierarchy or if you built the dlls yourself they were likely created when the dll was compiled and linked - if possible, go back to your VS2008 development machine and see if you have any *.manifest files created when you created the dlls. Without the manifest files, your dll can't link to the ms runtime library dlls because they aren't registered in the system registry and there's no information about which SxS files should get loaded. Please note that all of this is pure speculation Here are some links that provide more (a lot more) information http://msdn.microsoft.com/en-us/library/ms973913.aspx http://msdn.microsoft.com/en-us/magazine/cc188708.aspx Maybe someone here really understands this stuff and can help. Mark

That's one of those really useful Windows error messages! My guess is that your dll is linked to the debug versions of some DLL - likely something like the msvcrtd.dll (the Microsoft C++ Runtime Library (debug version)) which gets loaded with VS but not with a standard Windows install - Windows will install the msvcrt.dll (doesn't include any debug info) but not the debug version. So, if your dll was built with the dynamic calls (http://msdn.microsoft.com/en-us/library/2kzt1wy3.aspx) into the debug library and the VS uninstall removed them, it won't run and you get the helpful error message. If possible, build your DLL with the /MD compiler option instead of the /MDd and this problem may be solved. If you can't recompile the dll (maybe it's not one you wrote) then use Dependency Walker http://www.dependencywalker.com/ to find which dll is missing that your dll is trying to call and find a copy of that dll and copy it to wherever your dll is looking for it. Mark

How about this? Just one event case handles the user interaction and the timeout Mark

John, This might be something that's useful (the third item on the page) http://forums.ni.com/ni/board/message?boar...=277358#M270293 I found this the other day when I was wondering about how to profile reentrant VI's. I haven't used it yet but it looks like you could have each reentrant instance attach their names to a message on entrance and exit and find out how much time is consumed (with the added complication of guessing how much overhead this call adds). Mark

It's a Republican Conspiracy - no wait - it's a Democrat Conspiracy - no, it must be Diebold's fault!!!!! We're doomed - AHHHHHHHHHHHH....................

QUOTE (bandersen @ Oct 31 2008, 03:21 AM) Use NI's Measurement Studio if you want to use the plotting features like the ones available in LabWindows or LabVIEW in Visual Studio. These toolkits are designed for Visual Studio and the .NET environment and there's lots of information, help files, etc. to do just what it appears you want to do. See this link for a quick description. http://cnx.org/content/m14741/latest/ I don't have any experience trying to call LabWindows libraries from Visual Studio, but the error you show in your original post is definitely a linker issue - your code is not linking properly to the libraries. I don't have any ideas about how to fix it. Lastly, if you have LabWindows/CVI, it includes an integrated development environment (IDE) and that's the best way to program in C and use the LabWindows libraries. Mark

QUOTE (kennoncotton @ May 15 2006, 09:32 AM) I'm running up against this same problem in an app I'm working on (in 8.2.1) and I have a couple of questions: First, is this still the behavior in LV8.6 when incuding project libraries? Or does 8.6 make handling this situation easier somehow? - I could migrate the project to 8.6 if that will help. Second, if I distribute the original EXE as a LLB (source distibution) it will have copies of the lvlb files that contain all member references, right? And then if I call this LLB from a shell EXE (that does nothing but call the LLB that used to be the EXE) and then the LLB that used to be the EXE calls into another LLB that includes a copy of the same lvlib, there shouldn't be a problem? Right? Thanks for any help! Mark

QUOTE (jdunham @ Sep 22 2008, 11:57 AM) Check out http://detritus.blogs.com/lycangeek/2005/10/event_log.html Mark

QUOTE (andymatter @ Sep 19 2008, 06:09 PM) OK, a couple of things I think I can answer - in your VI example, you show an attempt to cast a .NET object created from an array to the struct - that won't work because the target struct is not an array - LV only knows how to create objects of the specified types listed in the help. Second, the actual layout of the data in the OVERLAPPED struct will always be exactly in the order described and will be packed as efficiently as possible (on byte boundaries) - that's what the [structLayout(LayoutKind.Sequential,Pack=1)] attribute means in the struct definition (http://support.microsoft.com/kb/922785). So you can always be sure the same data will be in the same place in the array. So in your alternative 3 in your LabVIEW code this will populate the correct location, although it is easier to create the buffer as U32's and then just address the array position. As far as byte order, it will be little-endian on little-endian machine (intel). But I'm not sure that really helps very much. Once you get past that, this starts to get tricky because this is "unsafe" C# code in the example - once you create an array of structs that contain hEvent handles as the last data element, now you have to use that in the code and make sure they stay in place. In the C# example, the array of OVERLAPPED structures uses the "fixed" keyword to make sure that the data array doesn't get arbitrarily garbage collected by .NET. You'll have to do the same thing with the data array you create in LabVIEW. So this starts to look like calling into a regular (unmanaged) DLL. This thread (http://forums.lavag.org/DLLs-that-expect-LabVIEW-data-to-stay-put-t8608.html) has some info about how to fix a block of memory in labview. So, what may work is to 1) Create an array of uints - the array should be mutilples of five 2) populate every fifth element with an event handle using the Pinvoke.CreateEvent (or you could bypass the double indirection of LV->.NET->WinAPI by calling CreateEvent from the kernel32.dll) 3) Use the LV memory manager (from the LAVA thread above) to create a block of fixed memory and copy the array into it 4) cast the pointer to this memory block into the .NET ref for the OVERLAPPED struct array 5) Watch for memory leaks - you now have lots of potential to create them All this is pure speculation so take it FWIW However, I read this in the CyUSB help "Again, the use of BeginDataXfer, WaitForXfer, and FinishDataXfer is the difficult way to transfer data to and from a USB device. This approach should only be used if it is imperative that you squeeze every last bit of throughput from the USB." Sounds to me like there's an easier to use synchronous method available. You can probably build your LabVIEW code on the synchronous calls and then add asynchronous capabilities easier using reentrant VIs and the VI server to launch multiple communication threads and don't fool with the internal asynchronous calls unless you absolutely have to. Mark

QUOTE (Jeffrey Habets @ Sep 8 2008, 02:03 AM) I second what Jeffery said - it's not a question of being able to explain the error after it happens, it's a question of knowing exactly what errors might be generated so I can make intelligent choices of how to handle them at run time in my deployed applications. Seems there should be a better way than just trying as many potential run-time scenarios as one can think of and then writing the code to handle the errors generated - what about those scenarios you didn't anticipate? Now I've potentially got a customer calling and asking why his system just generated some error that shut down his test when if I had explicit knowledge that error could be generated I might have been able to handle it much more elegantly. Mark

OK, I'm a little late to this thread, but I was just coding in LabVIEW and trying to do some intelligent error handling and 1) either I identified a glaring deficiency in LabVIEW or 2) I'm just ignorant and don't know where to look, but is there any document or help file or something that specifies what error codes LabVIEW functions return? And I don't mean an error code list that has headings like "General" - 1094 - 1157 where I get to guess which one gets generated or just try to handle the 64 possible errors. I mean something like the MSDN on-line support where I can find which exceptions a method is expected to throw in the documentation for that specific method. I open the LabVIEW help for a given function and sometimes there's some info (like for Obtain Queue) but most often there's not. This makes it really hard to anticipate and handle run-time errors - what do you guys do?

If you're comfortable with .NET and don't mind a Windows-only solution, I've had good luck with the .NET products from Advanced Intellect ( http://www.advancedintellect.com/ ) I haven't used them with LabVIEW (I used them with C#/Visual Studio 2005) but they worked well for secure email and I got good support from the vendor. It should be relatively easy to create a dll (assembly) with methods optimized for calls from LabVIEW. Mark

Don't know if this will help or not, but I had a similar problem in that I kept getting the message a file was missing and I could not find any missing file. I started eliminating VI's until I could get the exe to build. Turns out that there was a single control reference that had the "Include Data Type" option selected. The control reference had been created from an old type def (no longer in the project). If the missing type def had been included in the VI, the VI would have broken and the problem would have been obvious. Just having the "Include Data Type" selected, even though the data type was missing, did not break the VI until building, when apparently the app builder looked for it and could not find it. Unselecting that option allowed the project to build. Mark

LabVIEW (I've got 7.1 thru 8.5 presently installed) has never had a problem on my machine w/Visual Studio 2005 Professional Edition and VSS 6.0 installed. I'm on WinXP SP2. Mark

QUOTE(CTITech @ Feb 21 2008, 12:08 PM) If you need traceability and precision for a mil spec/medical measurement, then you really ought to consider using a calibrated DMM. The time you'll save in configuring the measurement and the added confidence you'll have (and paperwork trail to justify that confidence) will be worth the money. Mark

I'm no expert here, but it seems like you could put a precision resistor in parallel w/ the resistor under test and use Req = Rt * Rp/ Rt + Rp where Req is the resistance measured, Rt is the DUT, and Rp is the precision resistor. Then solve for Rt. Size the precision resistor so that the Req is always under 10K even when testing the 300K resistors - this should be a little more than 10K for the precision resistor. Mark

I have a copy acquired in the last six months or so that replaced one that I loaned to a colleague. He had an unfortunate incident with a diet soda, I believe, and he graciously replaced my original. The diagrams in this printing, while I would not call them "Art Book" quality (well, I really wouldn't call them even "Comic Book" quality) are readable and the book is useable. Mark

QUOTE(tcplomp @ Feb 13 2008, 07:19 AM) Ton, Thanks for the reply - Here's why I think LabVIEW doesn't support the IPv6 protocol http://digital.ni.com/public.nsf/allkb/46A...6256D4B005D3016 which says (dated 07/19/2007) "Problem: Does LabVIEW and/or the Internet Toolkit for LabVIEW support the Internet Protocol version 6? Solution: No, LabVIEW only supports IPv4. National Instruments will continue to monitor the demand for IPv6 and may add support for this technology to future releases of our products." Yep, I would have expected that the protocol would depend on the what the OS supports (WinXP in this case), but to keep LabVIEW platform portable maybe the implementation defaults to the lowest common denominator (IPv4)? As far as what's so special about the hardware? Beats me, but the DUT's are a suite of devices that communicate with each other using IPv6 protocol and we have to be able to generate and receive command and control messages using IPv6 so we can emulate system hardware with the tester. Thanks, Mark

I have just joined a project where we need to communicate with custom hardware using the IPv6 protocol. A quick search indicated that LabVIEW does not support the IPv6 protocol (someone PLEASE tell me I'm wrong!!!). The intention was to use LabVIEW for this project since we have a team of experienced LabVIEW developers and we need to control other instruments over serial and GPIB - not to mention that we have a very short time to delivery and LabVIEW is about the only tool that gives us any chance of success! I'm an experienced .NET developer, so my first thought is to create a .NET DLL that wraps the IPv6 networking tools available in the .NET 2.0 (or 3.0, although I haven't used it) framework and call that from LabVIEW. I'll build a LabVIEW wrapper around the DLL that encapsulates all the functionality so that the DLL could actually be anything that supports IPv6 - the reason for this is that somewhere down the road the customer may ask for inter-platform portablility (to Linux) and then the DLL could be replaced with a .so (is that right? My Linux knowledge is pretty rusty) and the code would still work. At any rate, we'll still have LabVIEW for all the UI, instrument control, configuration control, etc. Please offer criticism of this approach and feel free to suggest any alternatives. Thanks for your help! Mark