Rolf Kalbermatter

Believe me, alignment is the smaller of the problems he is encountering. The bigger problem is the lack of understanding C pointers, strings and all that and that LabVIEW strings are something very different than a C string. That together with proper memory allocation and deallocation rules for any pointer you use. I lost at some point my patience and found that ned was doing a better job in trying to teach him a little about C programming than I could bring up to do, so left it at that.

Technically there would be a way to solve this in LabVIEW for almost all instances. The Windows API has generally ANSI functions and Unicode functions for all File IO functions. If they would choose to use explicitedly the Unicode variant internally and make the LabVIEW path to Windows path function a tiny bit smarter they could have solved that years ago for all OSes since Win2K. Since Paths are in LabVIEW a distinct datatype the entire modification could have been done transparently for LabVIEW diagrams without compatibility problems. Why they didn't do it back in LabVIEW 8.0 when they modified all file functions to work with 64 bit file offsets to allow for file access for files <2GB is still not clear to me. It would have been an invasive chance in the LabVIEW source code only with almost no chance for any negative influences for LabVIEW applications. Changing the File functions to use Unicode paths internally would IMHO have been a less involved exercise than supporting 64 bit file offsets throughout. Not to say that 64 bit offsets are not important (they are) but allowing paths to go beyond 260 characters is also a pretty important feature nowadays (and would have been a great opportunity to support 10 years ago when this generally wasn't a real issue for most computer installations).

Well there is a chance that it is not really an out of process invocation. But a LabVIEW DLL consists of 3 things. 1) a stub loader 2) a C compiled wrapper for each function 3) the compiled LabVIEW VI (and subVIs) for each function The stub loader is responsible to locate the right LabVIEW runtime and load it but does skip that if it determines that the current calling process already contains a compatible LabVIEW runtime of the same version. This can be also the runtime environment of the LabVIEW IDE. This not only speeds up the initialization of the DLL but also allows more efficient passing of function parameters since otherwise all parameters need to be copied from the calling environment into the DLL environment, as Shaun has quoted already. So while the LabVIEW DLL is loaded into the process, it is not entirely sure if the LabVIEW runtime is also loaded into the same process if the stub loader determines that the current LabVIEW runtime kernel can not execute the VIs in the DLL because of version differences. While possible it certainly poses some difficulties in terms of heap management but out of process invocation would also cause its own kind of challenges.

I regularly do to find hidden objects in a diagram of inherited code but normally ignore the useless unconnected terminals warning. This last one was maybe sort of useful in old days but nowadays with event structure and what else I often end up with terminals just laying around in the according event structure without ever needing to be connected. For the rest I'm with everyone else here: Don't treat an analysis result like race conditions as a breaking error. It's a serious warning (unlike unconnected terminals) but certainly shouldn't break code execution by its own.

Geez, I completely forgot about asynchronous VISA. It has been years that I had to tinker with that because of flaky devices drivers.

Are you using any Call Library Nodes in your code? If they are from NI libraries they are likely ok but anything else is suspect. Badly configured Call Library Nodes or buggy external shared libraries have the potential to create exactly such problems. And LVOOP has the potential to be extra susceptible to such corruptions, but unless your LabVIEW installation itself got corrupted somehow is by no means the cause of them.

10 MB per DUT fully multiplied by the number of DUTs! That make me believe that you might have been setting reentrant on all VIs just to be on the safe side. While possible and LabVIEW being nowadays able to handle full reentrancy this is not a very scalable decision. Reentrancy by parallel VI hierarchies is often unavoidable but that should be an informed decision on a per VI case, and not a global setting.

Simply use an InitializeArray node with the datatype being U8 and length >=120, then convert it to a String with Byte Array to String. Changing the Call Library Node parameter to be an array of U8 would work too, but you would end up with a string that always contains 120 characters, but only the characters until the first NULL byte are meaningful. If you configure the Call Library Node to be a CStr pointer LabVIEW will take care on return to scan the string for this NULL character and limit the string length to be the correct size.

I've seen similar things occcasionally also in at least LV2013 but nothing that I could pinpoint and so far I think only in applications I received from others and most likely also were originally from an earlier version.

That means that there is still something wrong. Either one or more Call Library nodes are still configured wrong or there is a bug in the flash dll somewhere. The most likely culprit is a badly configured Call Library Node. Have you made sure that any function which returns information in a string or array buffer is called with a properly allocated buffer? If your buffer is even one byte smaller than what the function is going to try to write into, it will inevitably overwrite some memory that will destroy something. This can often result in a 1097 error if the overwriting is serious enough but also can go unnoticed until you try to close LabVIEW and when trying to clean everything up, it stumbles over the corrupted pointers. Or it can crash somewhere between where the overwriting happens and closing of LabVIEW. And if the overwriting is not affecting pointers it may be in data that your program uses to do calculations elsewhere.

From what John describes in the first post, I would be surprised if his application gets even remotely close to 1GB of memory consumption. In my experience you only get above that when Vision starts getting involved. That or highly inefficient programming with large data arrays that get graphed, analysed and what else in a stacked sequence programming style.

Well!!!! If you add a call to FlashErrorText() after each failed function call you will find out that it first reports after the FlashSetupAndConnect(): then after the FlashErase(): which is logical since the SetupAndConnect call had failed. So what does this tell us? The flashaccess.dll attempts to find the file cpu.ini in the directory for the current executable. Unless there is a way to tell the DLL in the ocd file to look for this elsewhere, you may be required to put this file in the directory where your LabVIEW.exe file resides (and if you build an executable , also into the directory where your executable will be). Basically it is a bit stupid from the DLL to look for this in the executable directory only and not at least also in the DLL directory itself, but alas such is life.

See above in my edited post. And from the example project you included it seems that cdecl is indeed the right calling convention.

Well I got rid of the dynamic path in the diagram and simply pointed the Call Library Node to the DLL on my system and then LabVIEW ends up with broken arrow for the VI claiming it couldn't load the DLL. Well disregard this remark. Typical PEBCAK problem . Should have noticed that the VI got opened in LabVIEW 64 Bit rather than 32 Bit. I have edited the VI in a way that I should think should work. Seems that LabVIEW feels the functions need to be called as cdecl. Not sure why since the assembly code seems to hint otherwise, but whatever. I now get a return value of 1 for the Disconnect call, which sounds not to bad. Obviously other than what you believe, the FlashSetupAndConnect() call has to fail on a system with no hardware to connect to! Just adapt the path generation to your conf file in a way that is working for your installation. usbWiggler.vi

What memory do you have in your machine? For the FPGA compiler it REALLY makes a difference if you can throw more memory at it.

There is absolutely no need for all the pointer stuff you are doing. The Call Library Node is very capable of translating LabVIEW strings into C string pointers for the duration of the Call Library Node call. Your own managed pointers would only be necessary if the lifetime of that pointer is required to last beyond the call of the function itself. So get rid of all the pointer acrobatic and just use the code in the true case. The DLL doesn't load on my system since it is compiled using Borland C and probably requires the Borland C Runtime library installed on the computer, which I have no plans to install on my system. However taking a quick look at the assembly would indicate that it might be compiled to use stdcall convention for all its functions. The header files or the MS Visual C example mentioned in the documentation would certainly help to verify what calling convention is supposed to be the right one. Also the return value of those functions is defined to be int, which under all modern Windows versions is a 32 bit integer. Your function thinking it's a int16 certainly might miss some interesting bits that way. Look at this declaration in the documentation: An int is still a 32 bit integer, and not a 64 bit integer as you have decided to make it here for the parameters (and still use an int16 for the return value)!!!! Last but not least: If you have several files to attach, with some of them being not possible to post because of their ending being rejected it is quite a good idea to pack everything into a ZIP file and post that rather than renaming files to make them appear as something they are not, and having to explain how to do all the renaming back in order to get the right files.

Depends what instruments that were. The key here is that they are USB, and lacking any specific USB Raw setup in your diagram, must be Virtual Comm devices, which means VISA does in fact very little itself other than talking to the Windows COMM API which then calls into either the standard Windows Virtual COMM USB driver or a specific Agilent/Keysight virtual device driver. Which one it is I have no idea. While VISA may be part of the problem I have seen all kinds of weird and unpleasant things happening with Virtual COMM USB drivers from various manufacturers. I have seen very little problem with parallel or any other type of VISA communication with other devices than COMM USB devices and since VISA really just treats them as any other serial port the problem very likely has to be searched in the USB COMM device driver, either the Windows standard driver or most likely a vendor specific device driver for the instrument you are using. Basically your instrument is pretty much the same as any of those RS-232 to USB converter dongles, and there it makes a big difference if one uses a noname product with unknown internal controller or one based on for instance the FTDI solution. While none of the standard drivers that come with the SDK for such chips is really meant to be distributed by OEMs to their clients, most (especially no-name manufacturers) do so anyhow as you really can't hire a programmer to improve a driver when you earn basically nothing on the sale of a product already and from the ones I've seen only the FTDI driver works reasonably well enough to not crash under any but very ideal situations. Another indication for this is the fact that LabVIEW simply disappears. No crash that can be produced in user space only is really able to terminate a process in such a way under modern Windows systems. This only can happen if a kernel driver is violating some critical system integrity while being called by the process directly or indirectly. And the only kernel component aside from normal Windows kernel handling in this setup would be the USB Virtual COMM port driver or some other part of the USB driver stack. This really only leaves two options for the cause of this crash: A buggy chipset driver for your system itself or a buggy USB virtual comm driver for your instruments. Both of them are completely out of control of VISA and even more so for LabVIEW. And while USB can potentially allow faster communication speeds than GPIB it is even less parallel than GPIB. In USB each bit has to go through the same line, while with GPIB there are 8 parallel datalines. Also both USB and GPIB do allow to communicate to several devices quasi-parallel. And since the USB port is really just used as a virtual COMM port in these cases the bit speed (baudrate) is typically limited to values way beyond what you could reach with GPIB.

Access Violation is a generic error that is generated by the CPU itself when a code execution causes the CPU to access a memory address that the virtual memory manager does not recognize as being assigned to the current process. Often it is a NULL pointer that is referenced, but any badly initialized pointer can be the culprit. It simply means that something got corrupted in the application memory, but there is no way to determine how it happened from the access violation exception information alone.

Yes I installed all my LabVIEW versions into the C: SSD. But then I got a 500GB SSD Mini-PCI card in my notebook besides the 500GB hybrid HD Sorry guys, but couldn't let this pass!

Actually NTFS supported symlink like features since its early inceptions, but there were only a few very obscure Windows APIs that allowed to create them properly. Recent NTFS versions improved on that a bit and Microsoft also added support for them into the shell. For all practical purposes support for symlinks in anything earlier than Windows 7 and 2008 most likely isn't of any interest anyhow since they are all unsupported OSes by now. The remark about supported OSes for a certain functionality is anyhow often misleading in MSDN. For one the documents tend to get outdated (notice the absence of Windows 7 which is more or less simply Vista but in a usable form) while on the other hand Microsoft tends to also update the documentation regularly changing support information to only mention the latest versions, even though that API or functionality really existed already much earlier. Most Windows APIs on MSDN claim to be supported since Windows 7 by now even if they already existed in Windows 95.

How do you read the characters from the Excel file? What Excel file is it? Basically xls files use binary OLE streams for data which stores strings as OLECHAR which is basically UTF16. xlsx files use xml with UTF8 encoding. But your problem is most likely that you use the ActiveX interface to Excel. Here LabVIEWs own smartness likely plays you some tricks since the strings provided by the Excel ActiveX interface are automagically translated into whatever is your current default mbcs codepage that you have configured for your Windows account. While LabVIEW can support Unicode in its string controls with the unsupported ini file setting, it's very much possible that this support does not extend to the ActiveX interface in LabVIEW and ActiveX being designed as idiot proof interface doesn't allow you to change that behavior.

While that is generally true it is IMHO a pain in the ass with no real advantage other than not requiring you do write a little C code and run it though a C compiler. Of course for someone who has no C knowledge, this option is all that is available to them, save from hiring a C programmer, but it is a bad choice for a lot of reasons. First, you need to know quite a bit about C programming anyhow to be able to make this work reliable. Second, the DLL will for all practical purposes not only run in a separate application instance but many times in a separate process. When you upgrade your LabVIEW code to a new LabVIEW version, the DLL needs to either be recompiled too every time or it will run in a separate LabVIEW runtime process that has to be the same version as in what the DLL was created. So unless you upgrade your DLL too, you will have to remember to install the runtime version for your DLL and the one for your application. Consider an app using more than one such callback functionality and you easily end up having to install several LabVIEW runtime versions after some progressive development of your app. And moving platforms (eg, Windows 32 bit to 64 bit) will most likely have every other user of your callback solution stumped, since the LabVIEW created DLL is somewhat unintuitive for most casual LabVIEW users (and illogical for more advanced programmers).

While NI goes to pretty extreme lengths to mutate code that has changed between versions when upgrading to a newer version the reverse is not as thorough. It possibly can be considered a bug, but the save for previous has never and won't ever guarantee that code will backsave without broken arrow in the older version.

Basically using the calls to MultyByteToUnicodeString() and UnicodeToMultiByteString() Windows APIs you can do every possible conversion from and between an MBCS encoding known to Windows. These functions accept as one of their parameters the codepage that the MBCS text is in. By default, one passes the CP_ACP constant there, which tells Windows to use the current user codepage, but if you know that your text is in another different codepage you have to pass in the according constant for that parameter to MultyByteToUnicodeString() and end up with UTF16 encoded string in the output.

Why should someone post a working ini file verbatim in a power presentation? The person creating this presentation remembered that PPFs are some restricted feature and simply changed a few characters.