Rolf Kalbermatter

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)!!!

This prototype seems very awkward. Passing a cluster by value means usually that all the elements in the cluster are normally passed as individual parameters over the stack. BUT there are several issues with that! First the fixed size string obviously can't be passed over the stack as individual bytes as that would blow your stack immediately. So it's likely that the C compiler would pass it as C string pointer anyhow, but likely means it is just an assumption from my side, I don't really know, and likely different compilers might think different about how to do that, so you are dealing with an API that is most likely not even compiler independent in this way. But the more interesting thing is that the function seems to return a pointer to that structure. However since the structure was never passed into the function as such, the C compiler would have to allocate it somehow. And now you have another problem to know how it does it. Is it a static memory area that is reused with every function call, causing nasty multithreading issues, or is it mallocing the buffer relying on the caller to properly deallocate it after each call?? And if it is using malloc, which one does it use??? Basically this function signature causes so many questions, und ambiguous answers that most likely will depend on the used C compiler too, that it is simply a stupid idea to even do in C, lets not talk about trying to call it from anything else. The only way to answer these questions properly is to dissassemble the DLL and check these things out specifically in the assembly code and then hoping that the DLL developer won't release a new DLL version that is compiled with a different C compiler version. If you don't find this worrying enough, I'm not sure there is anything that would worry you in this world! Well I now see that it is your DLL!!!!! Forget it and change that signature immediately!!! 1) Pass this structure as a pointer parameter, then Adapt to Type will generate the correct parameter passing. 2) Do NOT use malloc in a function to return memory buffers to the caller UNLESS you also provide according exported functions to the caller to deallocate those buffers. The malloc/free used by your DLL is only guaranteed to be the same malloc/free used by the caller, if both are compiled with exactly the same C compiler and the same linker settings and those linker settings don't include the static C runtime library into you DLL. Something you generally NEVER can assume when using DLLs, and in your case anyhow not true, since your DLL is generated using gcc while LabVIEW is compiled using Visual C. And various LabVIEW versions are compiled using different Visual C versions, with each having a different C runtime library. But don't believe gcc is better in that respect!

Man you must have a lot of idle time. As far as documentation goes for the binary VI format, all I know is that it basically follows the Macintosh resource format from the good old Mac OS Classic times. That knowledge allows to identify and access the various resources in a VI but of course is just the container format not the understanding of the individual formats of each resource type. While some of them used to be fairly similar to classic Mac OS formats, others and that is the majority of the VI resources, are very LabVIEW specific and the LabVIEW developers more or less threw together whatever they felt was necessary into a C structure and then flatten that to the resource stream. Without access to the LabVIEW C++ source code it is basically impossible to decode these resources in a meaningful way and even more difficult to modify them and write them back into the binary VI structure. VI Explorer really doesn't seem possible to do without access to the actual LabVIEW source code, which would have to be gained either illegally or caused by a preachment of at least some non-disclosure agreement. Also many of the bigger resources are currently ZLIB compressed which adds an extra complication layer into this all. Personally I think your best (and almost only) bet to get at these informations is to apply as LabVIEW developer within NI, but expect them to require you do sign some NDAs before you start, and they will do a good screening and some of your posts in the past may be a bit of an obstacle for that.

Well the next step in debugging this, would be to enable another mode on the read side and see what data actually arrives. Then comparing that data with what you think you sent on the cRIO side.

With your arguing about this being a failure of LabVIEW, all guns would come with a protection that they can't fire at all, so nobody can get harmed.

You use buffered mode, This mode only returns: 1) once timeout has expired, without retrieving any data 2) whenever all the requested bytes have arrived Seems your communication somehow looses somewhere bytes. With buffered mode you return with a timeout and the data stays there, and then gets read and interpreted as anothere length code sending you even more into the offside.

Same as JKSH. Just because I can make a super-mega-prontosaurus cluster (and have seen some people do that) it would never ever come into my mind to do that myself. Same about C++ object hierarchies that are cascaded over umtien levels! Your example simply points out that LabVIEWs datatype handling is not only highly recursive, but also able to handle that. As far as practical usage for such a beast, it ranges even lower than my super-mega-prontosaurus cluster mentioned earlier.

There are many possible reasons. Not all may be considered by NI but some of them for sure. Professional FPGA development tools are a pricy thing. LabVIEW is in there somewhere in the lower middle of the price range with other solutions from Cadence and similar being considerably more expensive. Also the FPGA compiler tools from Xilinx themselves as well as other FPGA manufacturers when bought for professional use have a pretty steep price tag. The sale of Spartan 3E tools has an entirely different meaning for Xilinx than NI. For Xilinx it is a means to get their chips used in more designs, for NI it is a means to get people distracted from buying cRIO and myRIO hardware. Even someone without a commercial background will be able to see the difference. You can't rationalize the decisions of a corporate company with your desire to get as many things as possible for as little money as possible. NI without doubt had to make a deal with Xilinx to be allowed to use their FPGA compiler tool chain within LabVIEW and even though Xilinx is of course interested to sell their chips in the end, they hardly will have presented their compiler tools, which represent a very major investment in terms of software developer time, for free to NI. So NI had to make a significant investment for the FPGA compiler integration into LabVIEW, both in terms of redistribution fees for the Xilinx compiler tool chain as well as the development work for the LabVIEW integration. Part of that cost get carried by the sales of the cRIO and other FPGA based hardware products from NI. When used with the Spartan 3E developer board there is absolutely no hardware sale involved for NI and you have pointed out yourself how there are tools out there to avoid even paying any LabVIEW fees to NI. So there is absolutely no interest for NI to support Spartan 3E and other non-NI hardware with their software tools outside of education. NI has a strong dedication to support educational institutions because some of the students may be working within NI over some time and others may be going to other employers who might be a potential customer for NI hardware in the future. Hobbyists as bad as that may sound, are much less likely to bring in future sales. They either don't work in an environment that is a potential customer for NI, don't have purchasing influence power, or if they work in a place that could be interesting for NI, they most likely have professional means to contact NI to get some loaner or other special deal for evaluation purposes. NI is not and most likely will never be in the market for hobbyist hardware. That market has a very low margin with very short product life cycle and hard to beat free software tools, although you have to accept that the quality of the software tools may at times be less than ideal and support for them may drop at the blink of an eye if the main developer finds another more interesting target.

While that is true, the property and method menus do get rather messy and unstructured when this is enabled so for normal development work I definitely prefer this option to be disabled. YMMV if all you do with LabVIEW is digging for rusty nails and other attic relicts.

My logical understanding of these terms is quite specific. Top Level VIs are VIs that run as the top of a VI hierarchy. They can be the main VI that starts a LabVIEW application but just as much VIs that get loaded through VI server and run as independent "deamons" in parallel with the rest of the LabVIEW application. They don't have direct links to the rest of the application other than through classical inter-application communication (IAC) means like pipes, TCP/IP, or files and quite occasionally Intelligent Global Variables, which don't classify as inter-application communication since they only work within the same process, but the principle is very much like IAC. In fact the main VI in most of my applications (the one assigned in the Application Builder as startup VI is only a loader with splash screen that then loads the actual main VI as another top level VI and runs it, after which the loader terminates itself cleanly. SubVIs are anything else when called by a VI, either implicitly by being part of the diagram or explicitly through the use of Call By Reference. They can show their front panel if they implement some form of dialog or other form of user interface but usually don't do so. The new Asynchronous Call by Reference "can" sort of create something in between but in most cases is more used like a Call by Reference with simply a delayed synchronization for the termination of the subVI.

I see! You let your embedded devices have a normal 8 hour working day and interpret the number of working days as hours!

This is not the same thing. Variant to Data can very well deal with arrays and even clusters as long as the data structure inside the variant is actually compatible. That doesn't even mean it needs to be exactly the same. LabVIEW will happily convert numerics and timestamps, etc inside the variant, into strings. It will only joke on fundamentally incompatible elements and some that are debatable if it should still attempt a conversion. On the other hand, the conversion from timestamp to string, or floating point to string for instance will use the platform specific formatting rules (system setting dependent). That is often not what one wants when it's meant for more than just display purposes. But LabVIEW hasn't a runtime mind reading interface (yet) . As to the original topic, I'm not sure I like it. The lazy dog in me says: sure it's fine! but the purist prefers explicit type definition for such things. Call Library Node is another function that also does attempt back propagation of types for "Adapt to Type" terminal, but this usually fails as soon as there is any structure border in between. And it can indeed cause nasty problems if one changes the datatype of a control downstream the wire without even a warning indication of a change to the Call Library Node configuration and suddenly the application crashes nastily.

Your Hex time is a so called timer tick time. Its counter starts at boot up of the system (or any other time your embedded system likes) and simply counts through, wrapping around after 0xFFFFFFFF (or 2^32 = ~4 billion) ms = ~ 4 million seconds = ~50 days. As such there is absolutely no good way to convert this into an absolute timestamp since its reference time (the 0 point) will be defined new every 50 days or so, or whenever you startup/reset your system. Your value indicates that your system was probably up and running for around 254688 seconds = ~3 days since last booted/reset. A day has 86400 seconds, so 254688 seconds certainly is more than 8.8 hours.

They are part of the LabVIEW code base.

Aside that it looks awful if you do not have a least a 60 inch screen, you never let the loop terminate programmatically. So to terminate your program you have to abort it. That does NEVER let the Close VISA function execute and your port stays open until you shutdown LabVIEW.

No that is definitely some DCOM issue. It very much depends how you setup the configuration of the DCOM authorization. It's a pain to get it to work at all already and therefore I actually always avoid this. Usually create remote apps that get installed under a specific account as service and then connect to them over TCP. Initially more work to do, but eventually easier to manage, as you don't have to fight DCOM (and with some customers also their entire IT department).

Hmm, you really just double clicked them??? With Vis from unknown source this is not very smart. You should always create an empty new VI and place an unknown VI on the diagram and then open it from there. These VIs are set to autostart when loaded as top level VI, and tinkered with so you can't set them to edit mode. If they contained bad code in the diagram, you would be hosed now!

You are logged in on that remote computer with an unlocked user session? And connecting to the LabVIEW instance over DCOM under this account? Maybe DCOM executes the LabVIEW process under a different account that has no desktop session available!

That's a dead end, unless you have VERY good dissassembly knowledge and endless time to tinker with. This DLL control is a real DLL. It is a C++ compiled plugin module that extends the internal object hierarchy by one additional class, each class being a specific LabVIEW control. The virtual table interface of such classes is VERY cumbersome to reverse engineer. Not impossible but REALLY VERY cumbersome. It's much easier to get an elephant to go through a needle hole than doing that! But it doesn't end there. You have to reverse engineer also the interface this class has to use to interact with the LabVIEW internal object model. This object model is loosely coupled with the object model as exposed by the LabVIEW VI Server interface but really only loosely. VI Server exposes some of the methods and properties of it, but by far not all, and is in fact a wrapper around the internal object model that translates between the C++ interface and the more strict LabVIEW VI Server interface. And my investigations into this make me conclude that it is not even fully extensible. The idea probably was to have a fully extensible interface but the controls who make use of this seem to rely on specific functions inside the LabVIEW kernel for itself, so unless one would only want to create slightly different type of existing controls by subclassing them it's probably not even going to work. This seems a very complicated business as there used to be another similar interface way back in LabVIEW 3. At that time the LabVIEW code was fully standard C only, but LabVIEW did anyhow use an internal object oriented UI control object hierarchy with messaging system and assembly written dynamic dispatch. A variant of a CIN code object file was used to add a new control into this control object hierarchy and the Picture Control was an addon package that seemed to use this interface, but in LabVIEW 4 the Picture control C code was fully integrated into LabVIEW itself and this object control interface was left in limbo only to be almost completely removed in LabVIEW 5, when a more extensive new object hierarchy was developed which went beyond just the UI elements and eventually used true C++ dynamic dispatch. The problem with this solution was that while LabVIEW evolved and had to add new object methods to its internal objects to implement new features such as Undo, the external code object created in an earlier version of LabVIEW and being embedded in the user LabVIEW VI, would still implement the older virtual dispatch table that did not have this method, so upgrading such LabVIEW code by the user to a new version would have been a rather problematic thing. Making this interface fully forward and backward compatible is an almost impossible task, but disallowing extension of the method table not an option either.

If you buy LabVIEW now you will get LabVIEW 2014. LabVIEW 2014 can't directly read LabVIEW 4 VIs. Almost 20 years is a long period and they had to do some cut at some point. Here you can see the compatibility table between LabVIEW versions. You will need an intermediate conversion package, which you should be able to discuss with your NI sales representative. It's basically an Evaluation version of LabVIEW 8.2 or 8.5 that can load and recompile older VIs to a format that the most recent LabVIEW version can read.

You seem to be using the VERY SUPER old original Database Toolkit with LabVIEW 4!!! You do realize that this software was released about 15 years before anyone even knew that Windows 7 might be released anytime soon???? Are you trying to load LabVIEW 4 on your Windows 7 machine? LabVIEW 4 was originally a Windows 3.1 application that used a special memory manager to support 32 bit operation. There was only a prelimenary version of it that was compiled for and working on Windows NT. While LabVIEW for Windows 3.1 could run in compatibility mode in Windows NT and even 2000, this compatibility mode was just a cludge and would badly fail as soon as you started to acceess hardware interfaces. That is not supported and will almost certainly fail in many different ways! I'm surprised that it even worked on XP even without hardware access but it's a safe bet that Windows 7 has probably broken something that would be necessary to run the Windows 3.1 version of LabVIEW on it. The way in LabVIEW 4 to interface to external code was through so called CINs. LabVIEW has changed a lot since those days and has subsequently removed the ability to create CINs in all versions of LabVIEW and eventually scraped support for loading CINs from all new platforms. This includes any new 64 Bit version of LabVIEW. Or are you using Windows 7 64 Bit and have installed a recent version of LabVIEW 64 Bit for Windows 64 Bit? As explained this version doesn't support CINs. The LabVIEW CINs are compiled binary resources similar to DLLs they have to match exactly the memory model of the LabVIEW application that you use. So there needed to be seperate CINs for LabVIEW for Windows 3.1, LabVIEW for Windows 32 bit, and about three versions of LabVIEW for Mac (Mac OS 9, Mac OS X PPC, Mac OS X x86) but there are none for LabVIEW for Windows 64 bit nor LabVIEW for Mac OS X 64 Bit and never will be. You may find the price of the toolkits expensive but unless you want to work with Windows XP or 2000 you really won't get around upgrading to newer versions. Besides working in LabVIEW 4 is a major pain in the a** in comparison with newer versions of LabVIEW. If you decide to upgrade at least LabVIEW, you can also look in alternative Database Toolkits on the net. There is one called LabXML and another one called ADO-Toolkit. There are others too but no matter which you choose none of them will support LabVIEW 4.0 so an upgrade of at least LabVIEW is unavoidable. Just FYI we are currently at LabVIEW 2014 which is about equivalent to LabVIEW version 14.0 in the old numbering scheme.

That sounds like a bad memory! There is a threadconfig.vi in vi.lib\Utility\sysinfo.llb that will configure LabVIEW and write the necessary settings into the LabVIEW.ini file. You can then copy them into your application ini file. That should be managed by Windows.