Rolf Kalbermatter

You can do that but you will have to get acquinted with some low level GPIB details and API functions. Basically a GPIB bus always has exactly one system controller (this is called SC in GPIB speak). This is normally the PC but since you have two of them you will have to configure one of them to be the system controller (that is the default for a PC GPIB interface) and the other to be not so. Then at any time there can only be one interface a controller in charge (called CIC). A system controller can at all times request control over the GPIB bus and therefore be CIC, aborting any ongoing communication by another controller that has been CIC. In order for a non-SC to get a CIC it has to wait for the current CIC to pass control to it. This all can be done for sure using the old traditional GPIB functions and I'm sure there are still some documents on the NI site explaining that. I have no idea if VISA supports multi controller functionality in any way. Last time I checked it didn't seem to. Rolf Kalbermatter

Probably not. Visual Basic does everything that does not fit into a string or a single variable with VARIANTs. VARIANTs are not so fun to deal with directly and you need a whole bunch of Windows OLE functions that are not available on non Windows 32 bit systems. Therefore LabVIEW chooses to convert incoming variants into its own binary format (well not really its own but the format used by virtually any real compiler, which of course leaves out Visual Basic) and reconvert them back when handing them back. The only real solution to speed these things up is to not use Visual Basic and/or Active X for such cases (or do everything involving such arrays in Visual Basic). My choice would be the first as I try to avoid ActiveX at almost all costs for its famous stability, version interchange compatibility, and lean and mean runtime system, not to mention its unparalleled multi-platform nature :-). Rolf Kalbermatter

Well, without LabVIEW DSC you will have to write your own DDE server. Let me tell you that that is no fun at all, as DDE has a few drawbacks nowadays. First it is an old technology and in some areas rather strange to use for nowadays understanding. Second it has a few quirks including in the LabVIEW interface and there is NO support for it anymore. Nobody at NI is going to look into a problem if you can't get something to work and there very likely won't be a bug fix of some sorts if it turns out to be not working due to some obscure DDE incompatibility with your Windows system. That said an Excel example is more or less all that is needed. It should show you the service name as well as the topics. What you may be running into is the NetDDE setup that is needed for networked DDE communication. There have been tutorials on NetDDE configurations for LabVIEW DDE on NI's site, but they were written for Windows 3.1 and Windows 95. You may be likely running into access right problems on more modern Windows NT based systems and need to figure out how to setup your system right to get around them before being able to access a remote DDE resource. Do the Excel examples work over the network, because that would indicate that the NetDDE configuration is more or less correct. Rolf Kalbermatter

Could this be something delegated to the scripting feature now? Would seem to me that you could enumerate the diagram or whatever and as one of the properties of a control or wire get its new 32 bit type descriptor. As such it is of course basically not accessible anymore. Talk about removing features due to an update! NI seems to find with every new version new ways to make a power user wonder if an upgrade is really such a good idea. Rolf Kalbermatter

Oh well, a closed discussion board. I don't feel like signing up to view what you refer to, but I guess I have some ideas. Happy holidays Rolf Kalbermatter

You can strip the front panel, but for the VIs you want to call dynamically you shouldn't do that. In order for the dynamic parameter passing to work the VI really should have it's front panel otherwise you will get all sorts of errors when trying to load such a VI dynamically and/or call it. Rolf Kalbermatter

You bring up points which have been discussed already here on lava as well as info-labview. I don't think you really want to tie the project hierarchy to a disk hierarchy. This puts up a strong limitation to what the project hierarchy can represent which is IMO not necessary. Other development environments like MS VC don't choose to synchronize the project hierarchy with any disk hierarchy either and I feel this to be a good choice. SVN and all the other SCC systems are not directly supported in LabVIEW 8 but LabVIEW makes use of the MSSCC API. This is a closely guarded trade secret of MS and you only can get the specs by sigining a NDA. As such it is not very likely that there will be Open Source implementations of MSSCC interfaces soon. However you can get PushOk's SVN plugin (not open source or free though) discussed by Jim Kring in another thread on this board, which interfaces SVN to MSSCC compatible development environments and in this way LabVIEW is just as compatible to SVN as it is to other SCC systems such as MS VSS or Perforce. The project explorer view is quite something to get used too, and it does have certain quirks at the moment which are sometimes just not intuitive and sometimes simply a bug. I expect most of these things to be ironed out in LabVIEW 8.1 ;-) Rolf Kalbermatter

Oops is that one of the super secret VI properties? Nope doesn't seem! It is in Execution->AllowDebugging. Rolf Kalbermatter

Back in my days at NI, CAR stood actually for "Corrective Action Request" and probably still does. The guy who wrote that answer probably just was tinkering about the creativeness he could do in writing a LabVIEW program instead of answering a technical support. Working in technical support can have this effect on you! :laugh: Rolf Kalbermatter

I usually do this by toggling the debugging flag twice. Snooped it from some LabVIEW internal functions some versions ago. 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