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

This DLL is a COM DLL and therefore does not export functions to call directly. As such the Call Library Node won't work. If the DLL contains a so called type library or at least is installed with a type library you have a chance to use the Active X interface in LabVIEW. However Active X comes in two flavours. One are Active X Controls which provide some form of user interface and can be inserted in the Active X Container in LabVIEW. The other flavour are Automation Objects without any UI component and they can not be put in an Active X container. Instead you place an Active X refnum on the front panel and then browse from there to the actual object you want to use. Then you wire that refnum to the Open Automation Refnum function which calls the OLE function to instantiate the desired object through the DLL proviced object factory in DllGetClassObject(). Once Open Automation Refnum returns successfully you should be able to wire it to the Property Node or Method Node to select the approriate property to access or method to execute. Don't forget to close the refnum at the end with Close Refnum to avoid memory leaks. Rolf Kalbermatter

I was looking into this lately and the scripting seems to be another feature which is put behind the new licensing scheme (together with XNodeDevelopment it seems). So there are really only two ways to get scripting in LabVIEW 8.0. The first is to get a license from NI to do that and activate it in the license manager, and the second would be illegal. Rolf Kalbermatter

Yep, Firefox download worked well too. Wouldn't ever have tried the same with IE though. Even 50MB files used to be a one out of ten chance to work. Rolf Kalbermatter

It doesn't seem to work overseas. Whatever serial number I could come up with from all the different SSP shipments etc. it kept telling me that it is an invalid serial number for the product I try to activate. NI support wasn't very clear but claimed that it doesn't work yet and I should just continue to use evaluation mode until I receive the proper SSP shipment. But that dialog at startup is for sure annoying. Rolf Kalbermatter

Because in all LabVIEW versions up to 7.1 the application builder has no possibility to add VISA or any other IO library installer such as NI-DAQ, NI-488, etc. They all do come with the apropriate hardware or can be downloaed from the NI site or copied from the Device Driver CD-ROM. In the case of VISA or even worse NI-DAQ it is not very likely, that everybody would want his installer bloated with 100ds of MBs of driver installation, which someone might have to reinstall anyhow because there has been a new driver version released since you built your app. Rolf Kalbermatter

LabVIEW itself has been always a nice citizen as far as undesired interaction with other installations on the same machine is concerned. I do not expect any difference with LabVIEW 8 unless the packagers at NI somehow messed up and built a bug in the installer. With add-on toolkits it is sometimes a different story. All native LabVIEW add-on toolkits should be fine but others such as IMAQ can be a bit problematic in certain cases. You may sometimes need to install certain bug fixes and definitely allow the Toolkit installer to also install compatibility VIs for older LabVIEW version into their respective directory. With drivers you have to be carefull to allow the driver installation (for instance NI-DAQ) to upgrade the (DAQ) VIs in the older LabVIEW systems, to sometimes allow them to continue to work with the new driver. These last two points where a Toolkit or driver for LabVIEW version X may also include VI libraries for LabVIEW version X-1,2,.. installations requires however that the older LabVIEW version is already installed on the system. Installing older versions of LabVIEW after newer versions is not a very good idea. Rolf Kalbermatter

The solution to this are subVIs and state machines and in my case also LV 2 style globals to encapsulate specific data and its operation on them. With this you can always get diagrams that fit onto a 1024*756 screens. My LabVIEW programs involving sometimes 800 and more VIs of all sorts of complexity seldom go over this margin and if they do it is only about the outer case or loop structure on one or two sides but never real code. An no, this does not require globals at all. I only use globals for some simple status variables such as a global application abort and application constants but never for other data variables. If I have to grade a diagram made by someone else, any globals other than simple booleans, or application constants automatically give negative points. So does not using state machines for user interface handling or not using subVIs. (and spaghetti code also scores high in my negative list). Rolf Kalbermatter

There is no native toolbar functionality built into LabVIEW yet. You will have to create the toolbar by adding small customized buttons to the upper border of your front panel and adding event support in your event handler for each of those buttons to trigger the corresponding action in your UI state machine. Rolf Kalbermattet

I wouldn't go and add datasocket to the complexity of the system. A simple TCP/IP server in the RT app similar to the DataServer/Client example will probably work much more realiable and not add much overhead to your app. While I didn't do that on RT systems yet, I often add some TCP/IP server functionality to other apps to allow them to be monitored from all kinds of clients. Rolf Kalbermatter

Unicode doesn't solve every problem there is. First there is not one single unicode standard. While Microsoft standardized on 16 bit Unicode (which incidentially does not have enough code space to represent every possible character on earth with a single unique code) Unix usually does standardize on 32 bit Unicode. Also the Unicode collation tables used by Microsoft do have some significant differences from the ones proposed by the Unicode organization. So implementing Unicode support in LabVIEW will NOT bring a single unified Unicode system across all the supported platforms but instead make it just about as difficult to write text in LabVIEW in a way which does show the same characters on all supported platforms as it is now. LabVIEW itself uses multibyte characters to support non western code pages (with the help of the underlying OS) and that while not perfect serves almost as good as a Unicode solution could do. And the biggest problem with global applications is not the character set but the different orientation some of the languages have in written text. For this there is no really good working solution yet, which would allow to write applications that can adapt to the different orientations by a flick of a switch and I doubt there is really a possible solution for this that can figure out this automatically. Rolf Kalbermatter

You summed up most of the negative sides of LLBs and got the rest of them in the other posts. I think using LLBs nowadays during development is a big no-no. I do use them sometimes for distribution of function libraries AFTER the development is finished and I wouldn't expect many changes anymore. Still this is only for distribution. The actual source code for further development or bug fixing is always kept in a directory instead and archived as such. Rolf Kalbermatter

It really depends what you want to do. A LabVIEW dialog is quite different from a Windows dialog. With Windows dialogs you could in principle use the Windows API to search for the default control to send a message to it to dismiss it. This wouldn't work for LabVIEW dialogs, since LabVIEW controls are not standard Windows widget controls but fully custom implemented by LabVIEW itself. The easiest way would be to post a return or esc key press to the keyboard queue. This assumes that the dialog has these keys assigned to its OK and Cancel buttons (almost alsways the case for Windows dialogs, but in LabVIEW dialogs implemented by VIs written by the application developer, this sepcifically has to be assigned by the developer). If this wouldn't work, you would have to distinguish between Windows dialogs where you would have to enumerate the controls in the dialog and then send a message to the correct control using Windows API functions or a LabVIEW dialog where you would use VI server to do the same. Rolf Kalbermatter

You can't really create Windows compatible binaries with the normal Unix versions of GCC. Ok, if you would be intimately familiar with all the in and outs of the Wine project you might be able to do that, but I doubt there are more than a few dozen people world wide who could do that. What you will need is at least a tool chain such as MinGW, with special support for Windows Portable Executable file format. Most easily it is done with Visual C. Rolf Kalbermatter

No!!!! 640*480 pixels = 300k pixels then make this color so you have probably at least 24 bits makes it already 900 k bytes and then real time means 25 frames per second at least, so do the math. Not to mention that you need at least double the network bandwidth of what you want to put through it. There are solutions to get real time video of this size through a normal network but they are special streaming protocols with patented compression algorithmes and not suited to be implemented in LabVIEW at all, aside from the royalities you would have to pay for such a solution. Rolf Kalbermatter

};has a sizeof(struct example) = 8 in most "C" implementations, but a "Flatten to String" and TCP Write generate only six bytes of output. So I've had to clean up those poorly aligned structures and stick a padding short between VariableA and VariableB. I have a couple of new questions I'll post in more appropriate places (feel free to help out some more!), but I wanted to express my gratitude for getting me "unstuck". Thank you! Yes LabVIEW uses byte packing on all platforms except Sparc stations as far as I know. This is because Intel and PowerPC CPUs have generally no big penalty in accessing operands on other boundaries than its integral operand size but a SPARC CPU has a huge penalty in those cases. Rolf Kalbermatter