Rolf Kalbermatter

Could be. Or if they are VIs from the LabVIEW DSC system or similar toolkits it could be the system flag for those VIs that also excludes them from being visible in the VI hierarchy and in eneral any search of any kind. Rolf Kalbermatter

Controls are entirely different objects than Nodes. I don't think you have any more distinguishable properties for controls than the Class Name itself. Rolf Kalbermatter

But it's truth. The big performance problem is not in thread switching here (thread switching while costly isn't usually where things go completely bad) but it is in copying the data. In order for the data flow paradigma to work without race conditions LabVIEW needs to make a copy of the data whenever a global or local is read. This is no problem for scalars but some people like to store x MB arrays in a global and read it every second to append a new subset to it and write it back. This is about the worst scenario you can think of in using globals. Thread switching however does occur when using the Value property since properties are executed in the UI context. So here in addition to possible performance loss because of data copy the additional two context switches will further increase the performance problem. Rolf Kalbermatter

Unfortunatly Lithium batteries have this characteristic that they will age independant of their useage. While it does probably make a difference if you use your computer often, unlike the well known problem of older battery technologies where not discharging a battery completely would considerably detoriate on the life time of the battery, Lithium batteries suffer from a general aging process that is mostly independant of their use. This means that such a battery stored for 2 years somewhere won't be much better than one that has been used for 2 years on a daily base. This is a general rule which has been described in several places. Of course there are differences. Some batteries will be absolutely useless after two years while others seem to be able to handle aging better. My former Dell had first a battery that was completely gone after less than a year (and I got a replacement under warrenty for it) The second battery which was used just as much did last 2 years and still was fairly well. My current Sony VAIO is about one year old and still going strong with somewhere around 3 hours of power outlet independant operation. But from what I have read so far it seems safe to expect that Lithium batteries usually won't last longer than about 3 years even if not used. I believe there have been recently new technologies introduced that should make the manufactering of Lithium batteries both cheaper and increase their life cycle too. Rolf Kalbermatter

The picture as you have shown it should actually work. Since the wire is going through the loop AND is not modified in anyway on its way LabVIEW will maintain the memory buffer for the time until the while loop is finished and it will 99.99999999% for sure not bother to reallocate or otherwise interfere with the buffer. As to your second question: This would be more proper and not rely on a specific wiring and/or LabVIEW internal mechanismes that "might" change with a future version. If you have a pointer you can actually configure a Call Library Node to call the LabVIEW manager function MoveBlock to copy data from and into this pointer from a LabVIEW array or string. Basically MoveBlock has following syntax: void MoveBlock(void *src, void *dst, int32 numByte); Configure the CLN as follows: Library: LabVIEW Function: MoveBlock Calling Convention: C return value: void 1st param: ** 2nd param: ** 3rd param: int32 by value 1st and second parameter depend if you want to copy to or from the pointer. Lets assume you have a pointer that you want to get data out then you would for instance configure the first parameter as uInt32 by value and wire the pointer you got from the allocation function to it (which of course must be a uInt32 too. The second parameter would be for instance an array of uInt8 passed as C array pointer. Make sure you preallocate that array to the needed size and then pass that same size as third parameter. This of course has a slight drawback of requiring an additional data copy (the MoveBlock operation) but will work irrespective of some not so intuitive wiring or not and possible pitfalls with future LabVIEW versions. Rolf Kalbermatter

The right way to deal with this is as JP Drolet has explained. Use the Format Into String function with the .; prefix anywhere you need to send decimal point strings. This way you do not rely on an ini file settting that can be hard to maintain for distributed applications. Where user interface things are concerened (or file output that is to be interpreted by other applications such as Excel) just use without prefix so that the user gets the format to see that he expects. For entry fields you should try to use the native datatype controls as much as possible. A numeric control has the logic to deal with platform specific user input and so does a data/time control. Trying to deal with this on your own is an exercise that needs LOTS of time. Rolf Kalbermatter

At least for LabVIEW 7.1 and earlier where this happens there is a simple fix. Press the Shift key and click on the Run arrow. This will force a recompile of the VI and cause LabVIEW to reevaluate the status of the VI. This error I have mostly seen with ActiveX, some .Net nodes and with Call Library Nodes. Sometimes the path in the CLN for instance doesn't match so LabVIEW can't load the DLL but other VIs using the same DLL have a good path and load it later on anyhow. LabVIEW then seems to have a problem sometimes to go back and update the status of those VIs that had already been loaded with a missing DLL link. Pressing the broken run arrow alone only will show the error dialog that correctly does not show any errors for the VI, but the broken arrow will only go away by a recompile. Rolf Kalbermatter

I don't think there are any editors for the PICC format outside of NI. And it wouldn't be very useful in most cases. What you can do is copying decorations and subparts from other controls in the customize mode and paste them into parts of your control. This works usually quite good, although there is every now and then a crash. The control editor is a great piece of work introduced way back in the earliest versions of LabVIEW but with certain limitations and crash potential and unfortunately it has never been substantially improved since. Rolf Kalbermatter

PICT is an old vector graphic format used on the Mac. LabVIEW supports PICT directly and can import them and use them and I do believe PICC is a similar but a little bit modified format for LabVIEW's native internal vector graphics. Rolf Kalbermatter

NI has an OCR add-on to IMAQ Vision. That works usually quite well. But: even with the best OCR software the biggest problem often is to get an image that has enough information to allow a software program to analyze it. Things like cameras used, and even much more important the lighting conditions are often the part where you will spend more time with experimentation, than getting the program to analyze the data and do something useful with it. Rolf Kalbermatter

IMAQ Vision comes to my mind here! But, to display the image it has to be decompressed and it for sure will use a lot more than those 1MB it takes on disk. Rolf Kalbermatter

As has been already mentioned in some ways, Toolkits installed (especially those that add a nice icon to the startup splash screen such as DSC, RT/FPGA, or IMAQ will cause LabVIEW to load additional VIs in the background that take up time too. So a clean LabVIEW is quite a bit faster in starting up than one that is loaded with every Toolkit there is. And a dirty Windows system partition certainly makes a huge difference. LabVIEw depends directly or indirectly on a lot of system libraries and they all have to be loaded and mapped into the process space of LabVIEW before LabVIEW can start to even initialize itself. A clean Windows installation will always startup processes significantly faster than one that has been loaded with 100ds of small little shareware programs, games and other little gadgets. Not to mention of all those little programs that show up in the status bar in some form or the other. A new installation of Windows is in general necessary about once a year unless you use your computer exclusively for one specific task and are not installing and uninstalling all kind of software frequently. Rolf Kalbermatter

Why! Just make sure you add those dynamically called Vis as such to your build script or Project. Or as alternative if you do this for plugin VIs that should remain outside of the application make sure you compute the right path when trying to load it. Of course there is the possible problem of plugin VIs using subVIs that were getting out of sync with the same named VIs used in the main application. This can be managed a little easier by using an All Project VIs.vi that contains all the dynamically called VIs as well as the main Top level VI. For editing the project you load this All VIs VI but you do not include that in the application build at all. Rolf Kalbermatter

No, it won't be possible. ActiveX is entirely based on COM/DCOM and that is one huge subsystem that has not yet been implemented by anyone outside of Micrososft. Wine as a project is trying to do that but they are still quite a stretch from a near full implementation. The only implementation of COM/DCOM I know of that has existed at least in the past outside of MS, was a DCOM implementation for Unix systems from Software AG. They had licensed the relevant code from MS and ported it to Unix and sold it for quite big bucks as a solution for big integrators doing banking applications and such. Not sure this is still maintained or sold. .Net is yet another rather huge subsystem that is probably build in parts on technology from ActiveX too. Trying to integrate both COM/DCOM and/or .Net in a RT system is IMO a rather useless exercise. Many things would interfere with the RT nature of the underlying OS and render it more or less to a "normal" OS. Also the foot print of the OS itself would get bloated extremely and would increase the cost for additional system resources. I think that if you do need COM/DCOM and/or .Net for something, an RT system simply is not the right choice for you. Rolf Kalbermatter

And what would be the problem with that? Move works both for files and directories. Move is simply the logical combination of Move and Rename into the same function. If a move happens on the same volume, the file data is not moved at all, but just the directory entry is changed. If it is on different volumes, rename would simply fail and move will correctly move the file or directory. This is how the modern OS'es do it at least and the old DOS rename and move functionality are just remainderes of a time when disk management was a lot more complicated and still had to be done partly by the application using it. The according commands in the Command line shell under Windows are simply built on the OS functions and written to emulate the old behaviour eventhough the OS functions underneath would be much more versatile. Rolf Kalbermatter

Either your TCP/IP address/name is not valid, your email server is not setup to listen at the standard SMTP port number or your network setup does not allow LabVIEW to connect to the computer where your server is installed. error 56 means timeout error so LabVIEw sends out a request for computer xy to accept a connection at port zz and never gets a reaction from there. This definitely is an error completely outside of LabVIEW. Try to ping the computer your SMTP server is installed on with exactly the same TCP/IP adress/name. If this doesn't work your address is wrong or a firewall disallows the traffic. If pinging works then again a firewall may be the problem disallowing specific traffic such as through SMTP ports or your SMTP server is not running or it is listening on another port than the standard port 25. Rolf Kalbermatter

That of course works if you use the standard analysis functions that were already available in earlier LabVIEW versions and as long as NI didn't change the actual function call itself. It won't work for newer analysis functions added in the latest LabVIEW releases or functions where NI added an extra parameter to support new behaviour. As mentioned just for a Mean calculation doing it in LabVIEW is actually faster, and avoids the external DLL/shared library ;-) Rolf Kalbermatter

LabVIEW has its own window manager building on the native window handling API of every respective platform. Most probably LabVIEW does maintain its own size attributes and also does some specific clipping on its own to increase performance or work around certain difficulties on some platforms. A lot of those manager functions are actually exported by LabVIEW (with the prefix W) but totally undocumented. For instance void WMove(Wind h, int32 h, int32 v); moves a window around and void WSize(Wind w, Rect *bounds); sizes it. The type Rect is documented in the extcode.h file. The difficulty is that the parameter Wind h is a specific LabVIEW datatype and does only indirectly correspond to the underlying platform datatype such as the HWND on Windows. LabVIEW seems to store this Wind handle at the 0 offset of the additional window specific data in the Windows window handle so doing: typedef void *Wind; Wind h = (Wind)GetWindowLong(hwnd, 0); should work in all Windows versions I have seen, but of course this is highly under the hood, undocumented and suspect to changes at any new LabVIEW version. Rolf Kalbermatter

But drag and drop from outside of LabVIEW is a big pitta to do right. An applciation can provide whatever format it thinks is right for the data and the receiver can only try to ask for another format but essentially has to deal with what is provided and that means a lot of potential conversion types. Asking for the disk path only is rather useless for anything but a path control and asking for the real data can give text, and image, formatted data etc. etc and then it is a big task to figure out how to convert that data to something you could use. Even more complex is the fact that Drag & Drop should work not just on Windows and with MS Office applications only but on MacOS, Linux and Windows with just about any applcation. This means that Drag & Drop events would need some multiplatform D&D manager in LabVIEW, which probably isn't fully there yet, and the D&D events will give you a somewhat complicated interface where you have to handle the recursive query of specific data formats until you get one that is provided by the data source and its conversion to something more suitable eventually. Rolf Kalbermatter

It is a good idea to always close any explicitedly opened refnums! Rolf Kalbermatter

Greate advice Warren! I second your warnings with the strongest possible meaning. Motion Control is not something you can do insecure at all. After all a finger is lost way to easily and for bigger motion systems worse things can and have happened. Rolf Kalbermatter

Are you now using the standard SMTP VIs that come with LabVIEW? What error do you get? In what low level VI (connection, when writing which command, when receiving after which commmand)? What LabVIEW version, which OS version, what email server,...... ? Rolf Kalbermatter