Rolf Kalbermatter

Please don't do that! The menu would get so cluttered it would be completely useless! LabVIEW has virtually thousend of options if you add everything together. Rolf Kalbermatter

You will have to call a Windows API function. Use the Call Library Node and configure it so that the library name is kernel32.dll, function name GetFileAttributesA, calling convention stdcall, return value numeric, unsigned 32bit integer, and one function parameter filenname of type string, C pointer. Now wire in the filename path to the parameter input after having it converted to a string with the Path To String primitive and the return value from that function contains a whole bunch of information encoded in the individual bits. Basically if the return value is 0xFFFFFFFF then there was an error such as the file was not present. Otherwise you can AND the return value with following values and if the result is not 0 the bit is set: #define FILE_ATTRIBUTE_READONLY 0x00000001 #define FILE_ATTRIBUTE_HIDDEN 0x00000002 #define FILE_ATTRIBUTE_SYSTEM 0x00000004 #define FILE_ATTRIBUTE_DIRECTORY 0x00000010 #define FILE_ATTRIBUTE_ARCHIVE 0x00000020 #define FILE_ATTRIBUTE_ENCRYPTED 0x00000040 #define FILE_ATTRIBUTE_NORMAL 0x00000080 #define FILE_ATTRIBUTE_TEMPORARY 0x00000100 #define FILE_ATTRIBUTE_SPARSE_FILE 0x00000200 #define FILE_ATTRIBUTE_REPARSE_POINT 0x00000400 #define FILE_ATTRIBUTE_COMPRESSED 0x00000800 #define FILE_ATTRIBUTE_OFFLINE 0x00001000 #define FILE_ATTRIBUTE_NOT_CONTENT_INDEXED 0x00002000 Some of them are redundant since LabVIEW returns them also in the File Info primitive. Enjoy Rolf Kalbermatter

Talk about installation size! VISA is small compared to .Net 2.0!! The only reason not to use VISA was really the very restrictive licensing and runtime costs. NI changed this licensing recently and now I do not see a pressing need to replace VISA with yet another even bigger monster. Besides you are not allowed to install .Net on anything but a genuine Windows system anyhow and for .Net 2.0 I would guess it better had to be XP or better or it won't install anyhow. Rolf Kalbermatter

TCP listen creates a socket and waits for incoming connections. This is in TCP speak the server application. TCP Open connects to a server and therfore is used in a TCP client application. In order to create a server which can simultanously handle several client connections you use the TCP Create Listener and TCP Wait on Listener which above mentioned TCP Listen combines but then only can support one connection. To get some examples search in the LabVIEW example finder for TCP/IP. Rolf Kalbermatter

I think in your case the second part of the message is the important part. For some reasons your VI has lost its diagram. Maybe you did set something wrong during the last build and the original VI was overwritten by the one build by the application builder which usually has no diagrams. I would do a reinstall of LabVIEW to get the vi.lib VIs back into original state. Rolf Kalbermatter

The license manager is very stupid. It only enumerates the license files present in your system and shows their status. It also can invoke the activation wizard for a specific license so that you can get a valid license. All the license files present in your system (such as the whole bunch of possible LabVIEW development licenses or the NIIMAQ1394) get installed with the respective NI software either with demo or inactive status. The license activation then gets an autorization code from NI (either by secure web, fax or email) and adds that autorization to the existing license file, signing the whole file with a code to proof that it is a valid license. Then the license manager will recognize it and so will LabVIEW. But LabVIEW checks also for other valid licenses for which no standard license file gets installed together with LabVIEW. Those queries will fail just as if the license file had not been activated or properly signed and the feature will not be available. Things I found that it checks for licenses are LabVIEW Scripting, XNode Development, Pocket PC, and Palm OS. So now we just need to get those valid licenses to use these features ;-) Knowing that the whole licensing is based on FlexLM I have a feeling that you could force it without to much of a hassle but that would be illegal! Rolf Kalbermatter If I would, I wouldn't tell! I like to sleep without being lifted off my bed in the middle of a night by a special police force ;-) Rolf Kalbermatter

The way the Yokagawa MX100 driver is constructed it may be almost impossible to get 10 ms update rates. They read in multiple times huge amounts of data for configuration, scaling and such both for the system and module level and write all that data back to the device too. I only managed to get everything working reasonably fast by diving deep in the driver and take it apart to optimize the number of buffer read and writes. However I'm only doing analog input here, so I couldn't specifically help you with your output problem and the code I have is not specifically neat or clean but just functional and very specific for the datalog problem I had at hand. Took me a day or so to understand the structure of the driver a bit and another day to get it working. Rolf Kalbermatter

I think an array of trees to be a bad UI solution. Aside of that it won't work in LabVIEW as you would like. A LabVIEW array element can only have different data for the individual elements in the array but shares all the attributes for every element. The data in a tree control is the tag of the currently selected node but the tree representation is really all constructed from attributes of the tree control and therefore will be the same for all array elements. But as said above I think you are trying to create an UI solution which will be anything than easy to understand for a potential user anyhow, so you really should reconsider your approach. Rolf Kalbermatter

It's just a guess but I have a feeling that the GetVIHierarchy... functions compute a signature of the entire hierarchy such that any changes to any VI in the hierarchy will likely result in a change of the VI hierarchy signature so that a tool can decide if some extra action such as saving (or maybe recompiling) needs to be done. I believe to remember that the signature is supposed to track almost any change to any VI in the hierarchy while the the GUID method is rather meant to only change on real user mods on any VI in the hierarchy. Rolf Kalbermatter

I work on and off on a few CVS managed projects including Wine and OpenG and even for text based programming merging is often not seamless. If you happen to have (even cosmetic changes) in the neighbourhood of changes made to the repository you end up with conflicts you have to merge manually too. As such the manual merging required with lvdiff isn't actually that much worse. If your mate is working down the aisle this may be an interesting work model but with distributed development as is used in most Open Source projects this is not a good solution. And once you get used to the update/commit model the checkout/checkin model doesn't look that attractive anymore. And yes it is a big question of personal preference (and sometimes company policy) although real developers tend to ignore company policies quite easily for all kinds of reasons, even artificial ones ;-) Rolf Kalbermatter

I think this is not really an option. You have worked with the DDK as you describe the situation or at least someone has done this for you so you should know how it is structured. Support for the DDK interface in LabVIEW is simply not a viable solution. All DDK binaries, import libraries, header files and other tools assume that the according software part is written in C and in certain situations even assembler. Creating bindings to access all this functionality from within the LabVIEW environment would be a project probably just as big as the whole NI-DAQ software or even bigger. Not to mention that LabVIEW is an application and Windows does not have any support for allowing applications to access Ring 0 functionality directly. I have no idea how this problem was solved with the Harris system but I suspect that it was far from a generic device driver interface which was directly available in LabVIEW but instead some (Harris developed) helper device driver which could be accessed from LabVIEW and which did translate between the kernel level and the LabVIEW application level a few things such as memory copies and probably translating interrupts into LabVIEW occurrences and such. As the Harris hardware was a closely controlled hardware and software platform with only a few parties if more than one at all involved in hardware, OS and device driver design it is probably a managable task to develop such a translation device driver. For a system such as a PC with its thousends and thousends of hardware and software manufacturers such a driver would always fail at least 50% of the possible target applications and with that is doomed to be a project that would cost way to much, not be applicable in a lot of potential cases and with that never gain enough momentum to ever possibly pay even a small amount of its development cost. Writing device drivers is a pain in the ###### to do, but it is quite likely a lot cheaper than whatever such a generic device driver interface in LabVIEW would need to cost to pay for its development. One possible option though which is not doing everything in LabVIEW but comes as close to it as it can come, would be to use the VISA interface to access a PCI hardware directly. It still will require you to know about your PCI interface everything you would need to know to develop the device driver as a kernel device driver and of course also quite some study of the direct hardware access interface in VISA but you could basically stay completely in LabVIEW to do this. It won't be able to reach the same performance as a kernel device driver optimized for your hardware but it is probably the easist and best solution if you don't want to deal with the Windows DDK at all. This option by the way has been in VISA since at least VISA 3.0. Rolf Kalbermatter

A normal LabVIEW application definitly and for sure will NOT run on an ARM Win CE system. LabVIEW is a compiler and creates machine code for the target CPU, for normal LabVIEW for Windows this is the i386 machine code. The ARM processor doesn't know what to do with those opcodes and Windows CE accordingly will refuse to load and start that executable. Theoretically the LabVIEW PDA mopdule for Pocket PC could support Windows CE, as Pocket PC is a newer version of Windows CE, but I have my doubts about if that really will work as there are differences between Pocket PC and Windows CE too. Rolf Kalbermatter

This can't work as you describe it. LabVIEW controls are almost all implemented in a LabVIEW native format and can't be accessed through ActiveX. You can however buy ComponentWorks from NI which supports similar control elements than what you have in LabVIEW. Another option is to put your VIs with the Application Builder into a DLL and call them as functions in your other language. This will however still display the entire front panel as a separate window and not as a control on the window surface of your foreign application. Rolf Kalbermatter

Windows does not support accessing the video interface directly from an application. You will have to use windows (as the name of the OS suggests :-) Seriously, forget about going to do what you want in the way you describe. Instead configure your notebook display adapter to split the desktop into two monitors, one on the built in display and the other on the external VGA interface. If you notebook graphics adapter does not support this your options are gone. You will need a notbook whose graphics adapter can control the external VGA port as a separate monitor. Now in LabVIEW execute the "App.Display.All Monitors" property node. The first cluster in the array should be your primary display and the second one (and more if any) are your secondary display(s). Now create a VI on which you display your image in a picture control and change its desktop position to values inside the rectangle returned in the second array element of the "App.Display.All Monitors" property node. Rolf Kalbermatter

Hmm, with the new CompactRIO you can bascially get even better reaction on external events then you ever could get with any preemtive multitasking or whatever OS solution. And with its price it really beats any potential specialized hardware/OS platform who might be able to support such a feature. Preemptive real interrupt handling in the user application level is something any non-specialized (aka very expensive RT OS) can't handle without throwing the whole system into a miriad of race conditions and other nastities. Rolf Kalbermatter

There is a data type format documentation PDF file from NI explaining it all. Basically the label (if any) is part of the type string. In your case I would think you labeled the control or constant as "Numeric 2" while the other is simply unlabeled (quite typical for constants). The first int16 defines the number of bytes in the "type string" and is of course different to account for the additional bytes for the label and the difference in the second is in the high order byte which is according to NI not documented. In reality it contains flags about the control such as if it is a control or an indicator and several other internal flags you won't need to know. Rolf Kalbermatter

When LabVIEW loads any VIs containing CINs or sometimes also other files, it extracts certain file components such as the CIN code resource from the VI and writes it in the temporary folder to load it from there. Obvious solution would be to adjust the temporary folder setting for the affected users to point to a directory they have write access to or probably less easy, change the standard temporary folder access rights to allow those users write access to it. Rolf Kalbermatter

David, No official announcement has been made. But Brian seems to have talked to someone from NI who did confirm my suspisions. I for myself have come to that conclusion after having searched for the new INI key to enable scripting but I instead came across some routines that also control the other licensing in LabVIEW. Rolf Kalbermatter

I'm afraid not. ActiveX does not support marshalling arbitrary structure data. Since LabVIEW does completely rely on the COM infrastructure to setup and configure ActiveX nodes correctly according to the information in the type library it can't create the correct type mapping due to lack of support for defining structure types in the underlaying COM architecture. .Net seems to have support for structure definitions but that is of little help here. Rolf Kalbermatter

MAX uses a COM like infrastructure to enumerate those devices. Each type of hardware interface has a DLL implementing a resource enumerator and property manager of some sort. This DLL knows how to invoke the low level interface specifiek enumerator functions of the respective interface library, which are different for every interface. The enumeration interface for the old NI-DAQ for instance was accessible through the DLL nicfq32.dll and its LabVIEW implementation was inside the NI-DAQ channel viewer support library in project/_res.llb in LabVIEW 6.1 and earlier. Of course password protected and as such almost useless. Rolf Kalbermatter

Probably a bug caused by the "agressive optimization" added to LabVIEW 8 according to some marketing hype I remember to have heard of. I would rather not have an utterly optimized LabVIEW compiler but a reliable one instead. Rolf Kalbermatter

Well with the much talked about scripting there is a way to change the path, but there is a big BUT or better two. You can only invoke scripting operations on VIs which are in edit mode so your VI containing the Call Library Node would need to be loaded dynamically, you would have to walk the VI object tree for the Call Library Node primitive change its path and then reopen it as strict type def again dynamically to invoke it with the Call by Reference Node. All in all a lot of work and in LAbVIEW 8 scripting is not available anymore without a license for this feature. Rolf Kalbermatter

If you check on the NI site for "remote Mozilla"you will find a number of articles. Yes Mozilla works the same as Netscape, but Firefox seems to be a differnt story. Not sure if LabVIEW 8 fixes that and has support for Firefox but earlier LabVIEW versions seem not to have support for Firefox for some obscure reasons. I would have expected Firefox to have the same plugin interface than Mozilla but that isn't so apparently. Rolf Kalbermatter

OPC probably never will run on real time. OPC is based on OLE and that is a huge system to add to a real time environment. As such it is probably not possible to create an OLE system that would not throw off any real time determinsme from the system. Also OLE is a closely protected core technology of Windows and Microsoft won't give out the source code just to anyone to port it to a competitive real time environment, even if porting it to a real time environment would technically be possible, what I highly doubt. So your options are actually to go with a completely VI based ModBus library. There are several Alliance Members that sell VI based ModBus libraries and NI recently developed one based on the ModVIEW library from CIT Engineering where I work. I'm not sure what NIs plans and conditions are for this library but you can also checkout http://www.citengineering.com/pagesEN/products/modbus.aspx. Rolf Kalbermatter