Rolf Kalbermatter

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.

Never having tried to look at the Project Provider Framework at all I can't really say for sure, but I would assume that in order to verify that a PPF is valid this check is done on every load, so is in the provided PPF base framework. With flarn having admitted to have broken password protection before it seems not so hard to guess how it all went. And yes, PPFs have the potential to wreck a LabVIEW installation completely and even worse modify code on the fly in a way that is very hard to detect. So this "signing" business is most likely much less about NI not wanting developers to be able to add plugins, but rather safeguarding those customers who have VERY stringent requirements about approved software running on their systems. They are out there and they have rules that even forbid to install OpenG VIs since they are not from an officially approved source.

The link gives an error and the main site is found suspicious by McAfee.

The easiest is most likely to use the command line tool of whatever GIT client you install. I do the same for SubVersion calling svn.exe with svn status --show-updates --verbose Parsing the return string is some work but easily doable in a generic manner that will work well. I'm absolutely sure that GIT works the same and this will give you a very flexible and easy to do interface without any need to go .Net, etc. Most of the tools you would otherwise integrate take the command line approach too in the end.

VI Server is meant to work between LabVIEW versions and platforms transparently. There shouldn't really be anything that could break. Well there used to be properties such as for platform window handles that used to be 32 bit only until LV 2009. They are now depreciated but still are accessible and if you happen to use them you could run into difficulties when moving to 64 bit platforms and trying to access them, remotely or locally.

Some of these objects have existed in LabVIEW for a long time and never done much more than crashing it! I assume they are cruft left over from some experiments that either were abandoned at some point or the guy who sneaked them in had suddenly left and nobody ever noticed it. The whole LabVIEW code base is huge and no single person on this world has a complete overview of everything that is inside it.

No, private nodes are yellow LabVIEW nodes that are not available in the standard palette (but can be generated with your "Generate VI Object method"). The idea is that your external shared library somehow creates an object reference somehow (usually a pointer to whatever your shared library finds suitable to manage your object) and then this object reference needs to be assigned to the user tag reference. This can be either done on the LabVIEW diagram with such a node after the call to the shared library function to create the object reference or inside the shared library itself by calling undocumented LabVIEW manager functions. Consequently there are matching LabVIEW diagram nodes or manager API calls to deregister an object reference from a user tag. But again unless you intend to start writing shared libraries (C/C++ programming) to allow access to some sort of device, or other functionality, this really isn't interesting at all to you.

It's a generic user tag refnum. The functionality behind it is relying on information found in the resource/objmgr directory inside LabVIEW. Basically the rc files in there can define an object hierarchy and for each object type you can define methods, properties and events that map to specific exported functions from a shared library. Once the generic tag refnum has been selected to represent a specific object type from one of the object hierarchies it is not generic anymore and you can not select other object types anymore from other object hierarchies. Also flags in the object type inside the rc allow to specify if the user is allowed to even select any other object type within the object hierarchy. It's all pretty involved and complicated (a single error in the rc file usually makes it completely useless and you can go and start guessing were the error is. To interface in a shared library to a LabVIEW VI user tag refnum you also either need to use some private diagram nodes to register the session handle returned from your shared library to a user tag refnum and also one to deallocate it, or use internal LabVIEW manager functions to do that. But unless you write drivers for some kind of interface in external shared libraries, the user tag refnum has no practical meaning for you at all. And it requires your shared library to be explicitly written to work with LabVIEW, it's not a means to interface LabVIEW to standard shared libraries at all.

If it seems limited to your PC then the most likely suspect would seem the network card and according driver in that PC. Wouldn't be the first time that network card drivers do buggy things. Maybe it has to do with jumbo frame handling. Try to see if you can disable that in the driver configuration. As far as I know cRIO doesn't support jumbo frames at all, so there shouldn't be any jumbo frames transmitted, but it could be that an enabled jumbo frame handling in the driver does try to be too smart and reassemble multiple TCP packets into such frames to pass to the Windows socket interface.

It's pretty common to have the male connector on the base board and the female part on the daughter board. I definitely have seen mostly this setup (and yes I talk about professional products here) if they didn't use some other special connectors altogether. One of the reasons probably is that the male connectors cost less and have to be always soldered on the board, while the daughter board is only sometimes necessary. They are not alone, look at the Raspberry Pi for instance which uses a male connector too. Both solutions have their advantages and disadvantages. As far as connecting cables, if you don't use flatband ribbon cables with IDC connectors, the male connectors require more expensive test lead cable connectors but unlike when pushing normal wires into female connectors, they won't damage the contact spring in the female connector. EDIT: And another reason is that the according male IDC connectors for flatband ribbon cables used to be not only exessively expensive but also often very hard to find.

I took a short look at your solution. While I can't determine if you have included all requirement tags (something you should definitely attempt to do as much as possible) the overall architecture looks certainly good enough. There is always something to say about a cleaner and more structured architecture but considering the time constrains of the CLA exam, you have to compromise and faster is certainly better than neat and clean in this particular case, although without some architecture you would fail too. Did you do all this in 4 hours?? If so, I think you are set for the CLA exam. If you needed significantly more time than 4 hours you may want to exercise some of the subsystem template implementations a little more to get them in as short a time as possible. As a pointer you may decide to actually do even less coding (not much more than the actual case and loop structures) and put a bit more prosa text in there instead. It may not seem to make a big difference but it's usually faster to write a short text than finding the correct node in the palettes and placing it on the diagram and wiring it up, often having to write some kind of comment anyhow too. And if you are familiar with Quick Drop set aside two minutes at the start of the exam to configure it to your likes. Also take the time to recreate your personal configuration as much as possible on a new LabVIEW install, exercise where the settings are beforehand so you don't loose time when configuring your machine on which you do the exam. An unfamiliar palette view, or auto-wiring or auto-tool setting can be a major pain in the ass when you are scrambling for time to get your CLA done, although it may seem only fractions of seconds you will loose each time.

Definit Definitely! They have been there since a long time. One of the possible reasons for the threaded "Insane VI" error messages in earlier LabVIEW versions. Your disk just isn't as reliable as you would like it and LabVIEW using a binary format for older files is very sensitive to even the slightest error there.

If you are going to write a wrapper anyhow I would forget about the stupid cluster and make it something like: void LV_some_func(char* data, int length, long start)  declare the struct in your code and copy the elements into it then call the API function.  void LV_some_other_func(char* data, int *length, long *start)  Here get the struct with the API function and then copy the contents into the parameters. Make sure to pass in "length" the actually allocated buffer length in the caller (your LabVIEW diagram), and to not copy more than that into the buffer. Then update "length" and "start" and return to LabVIEW. Something along these lines± void LV_write_block(const char* data, int length, long start) { datablock block; block.no_of_bytes = length > 10240 ? 10240 : length; block.start = start; memcpy(block.data, data, block.no_of_bytes); write_block(block); } void LV_read_block(char* data, int *length, long *start) { datablock *block = read_block(); *length = *length > block->no_of_bytes ? block->no_of_bytes : length; *start = block->start; memcpy(data, block->data, *length); deallocate_block(block); // This depends how the block is allocated. // If it is a static memory then this would be not possible. } But as pointed out before, the struct containing fixed size arrays being passed by value is likely a problem when not using the same compiler for your wrapper DLL then what was used for your library DLL you want to interface. And just for your information, long is only a 32 bit integer in Windows, even when using 64 Bit Windows and LabVIEW. long is only 64 Bits in 64 Bit Linux (and similar unix environments)!!!