Rolf Kalbermatter

This VI just calls into a private LabVIEW function with the Call Library Node. Not much you could learn from this other than that you can actually call into LabVIEW itself with the Call Library Node to call any of the functions documented in the External Code Manual. NI password protects these VIs because it considers those exported functions private (they are not documented in the External Code Manual) and wants to reserve the right to change or remove them in the future. Yes the data of a Picture Control is the stream of drawing commands. And its value therefore will be the last drawing command stream passed to it. Instead of flattening the data and parsing it you can just as well create a local variable and read the data and you will see the last stream of drawing commands passed to the control. No, the Picture Control is a fully build in LabVIEW control. It was added in around LabVIEW 3 to the build in controls of LabVIEW but at that time was a separate toolkit which installed the FP control and the Picture Control Toolkit functions into the vi.lib directory. Still the control was actually part of the LabVIEW executable itself. However it was added into the standard LabVIEW distribution later on, but it is a LabVIEW control just as the numeric control or any of the graph controls with exception of the 3D control. But I think this control doesn't even maintain a pen location at all after the drawing command stream has been evaluated. Wouldn't know for what it should maintain that as it directly translates the drawing stream commands into Winows GDI drawing commands. Try to do a Draw Line function without a Move Pen function first and you will see that the line always starts at 0,0. Rolf Kalbermatter

LabVIEW does some optimizing when writing to terminals and local variables. Unless you set the control to update synchronously, LabVIEW only posts the new data to a buffer and signals the control that it should update without waiting for the control to redraw. The actual redrawing is done in a different thread, the UI thread, not more than 50 times a second if necessary at all. This is still much faster than even the fastest human could distinguish the data. For the Value property LabVIEW does nothing at all like this. The property node will hang in there and only return to the diagram, after the new values have been redrawn in the control, which for a graph is typically a very lengthy operation. So for the terminal and local variable the diagram can continue to execute other code or in the case of a loop recalculate many new data before the graph is completely redrawn, while for a value property the actual redrawing of the graph will limit the speed the loop can execute. Consider for updating different controls depending on some other condition a case structure instead. Your programs written in such ways will typically perform much better. Rolf Kalbermatter

Not that you would probably get much from the diagram! The actual code is most probably almost all implemented in C inside a Call Library Node or a Code Interface Node. Rolf Kalbermatter

While it will be virtually impossible to create a LabVIEW routine which could beat an optimized C routine, the speed difference in general is not very large, as long as you understand how LabVIEW handles the data. LabVIEW always uses resizable data structures for arrays while in C you typically work with preallocated memory chunks. The reason is simply because in C you have to deal with memory allocation and deallocation anyhow you usually won't even think about reallocating an array in a loop as you add new values to it. LabVIEW doing all the memory allocation stuff for you, it is easy to build a loop where you use the Build Array function to construct an array and then people are surprised that this loop takes ages to execute. Instead using the auto indexing feature on the tunnel of the loop border (or sometimes for more complicated solutions doing a preallocation of the array with a shift register on the loop and a Replace Array function inside the loop) will basically create a loop which does at least as well as a non-optimizing C compiler will do. So in general speed difference in typical applications between LabVIEW and C, if you know what you are doing in LabVIEW, is minimal. The only areas where LabVIEW usually will be hard to code in a way which comes close to a well programmed C code program is for algorithmes with lots of bit manipulations and complicated array manipulations. The most important difference between LabVIEW and C in my opinion is that you can write quite extensive LabVIEW programs, albeit quite often with very bad performance and architecture, eventough you have no idea about programming, whereas you need at least a good basic idea about programming before you can create even the most simple C program. Java having similar high level advantages as LabVIEW such as implicit memory management etc. will basically suffer from the same issues where you can write very bad performing routines if you don't know how to make the algorithme in such a way to help Java use the best programming structures for the problem at hand. Rolf Kalbermatter

I'm very curious about remote debugging ;-) Rolf Kalbermatter

Aah, they do that already!! It is called garbage collection and kicks in as soon as the top level VI invoking the Open refnum function is going idle. This is actually a feature you can't turn off other than for VISA refnums (yeah I know they are now VISA resource names but the underlying mechanism is still a refnum) in the Options->Miscellaneous dialog. Rolf Kalbermatter

I hope you do not consider my remarks as saying IVision is a hobby project. It is far from that! What I was saying above is that a lot of professional users will prefer IMAQ Vision because it is from a well known party (namely the makers of LabVIEW), and they feel more comfortable to deal with a company of that size, which gives them a certain feel of safety. This is not just about IVision but in fact about any Toolkit ever released for LabVIEW. The NI version doesn't necessarily have to be better to sell, whereas as an independant developer you really need to have some really good aces in your sleeve to get even a small part of the market. This is and has been the case since the beginnings of 3rd-party LabVIEW toolkits although back in the early days it may have been a little easier sometimes. Though just consider that the two most successful 3rd-party Toolkits (Radius or so Database Toolkit and Graftek Vision Toolkit) really got bougth after some time by NI, and the rest have died or suffer a low volume existence hardly paying the administrative costs for distributing them. Some people will find IMAQ Vision to expensive for what they want to do and will be looking at IVision. The few who are left after that because even IVision is considered to expensive (for professional use that is as for the rest the evalution version probably will work well) are probably not very interesting to carry a project of this size. They will consist of people doing this just for a hobby or being in education where time spent is not an issue. However even for the last group this project is way larger than what a typical student could possibly manage in a semester work or something like that. And this would assume that such a student already has quite some knowledge about LabVIEW, LabVIEW external code, C programming and image analysis theory. I for my part can shine in the first three categories but lack in the last one considerable knowledge to carry such a project myself. Besides I have other priorities at the moment. Rolf Kalbermatter

If you control both sides of the connection it would be simple to create two small applciations to do that. IF the other side is however already provided it will all depend on what protocol this applciation does support and if that protocol has some file transfer capabilities such as FTP would have. Rolf Kalbermatter

You can call external VIs from an executable using VI server. However you have to be aware of a few things. 1) The VI must be in the same version of LabVIEW as was use to create the executable. 2) Calculating the path of an external plugin VI in respect to the VI inside the executable needs to take into account that a VI in an executable is always at the path <application directory>/<your exececutable>.exe/<your VI>.vi So assuming the plugin VIs are located in the same directory as the executable file you need to strip two times from the path you get from the This VI Path node and then append the VI name of your plugin. 3) The plugin must be able to reference any and every subVI directly. This means any subVI used by the plugin not already contained in the executable needs to be copied at a place where the VI can find them. Just copying the plugin VI into the application directory will in most cases not work. Better would be to load the plugin VI in LabVIEW and then Using Save with Options save the entire hierarchy to a new location, using LLBs, including vi.lib and any other option in the selection in the dialog and then save it. Move that LLB into the executable directory and adjust the path mentioned in point 2) to also account for the new LLB name in the path. This solution isn't very nice in that each plugin will contain all subVIs eventhough they might be already present in another plugin or the executable itself. It will however run as long as you don't happen to create two different subVIs having the same name. To get a more elaborate plugin distribution with plugin specific functions in the plugin LLB and the rest being added to the executable or some support LLB is far beyond a short esxplanation like this. It basically won't be possible without some custom made tools, where the OpenG Builder may actually be a good starting point to go from there. Rolf Kalbermatter

It probably won't help in this situation alone. I believe that the location and version of the Math Kernal Library is registered in the registry too at install time and this is used on load time of the lvanlys.dll to link to the appropriate DLL. This is the reason you get the different error message as the DLL can't find the registry entries or the DLLs and therfore has to abort as it really is only a wrapper around the Math Kernel libraries. Of course you can try to figure this all out but chances are that the Math Kernel Libary or something else will change again in the next LabVIEW version and then you can either decide to stay with your current LabVIEW version, try to figure out the new dependencies, or go with the flow and use the Installer anyhow. Expect this to be a never ending battle if you don't want to go with the Runtime Sytem Installer. Rolf Kalbermatter

The version information is just another resource in the executable image resource table. However there is no built in functionality in Windows to add resources to exectuables files as far as I know. For this you need so called resource compilers which are usually part of any C/C++ development environment. I believe there are open source variants around although their quality and ease of use as external tool from other applications does vary. One possible canditate should be contained in the MingW tool chain which is a Windows compiler and linker based on the every so popular Gnu C compiler tool chain. Rolf Kalbermatter

Very simple. Create two LabVIEW strings with the correct size. You can use the Initialize Array function to create two arrays of the necessary size of U8 numbers with the value 0. Then use the Byte Array To String function to convert these arrays in a string, place a Call Library Node on the diagram to call your _getUser function and pass the two strings at the appropriate location to that Call Library Node configuring them to be a C String pointer. LabVIEW will take care about passing the correct pointer to the DLL and on return will truncate the string to the actual filled in information up to the terminating 0 byte character. Basically the calloc is done through the Initialize Array function and the free is done implicitedly by LabVIEW as soon as the string is not anymore used in the diagram. Since the allocation and freeing of the memory is done by the caller (here LabVIEW) there is no need to use a particular memory manager instance. The function will just take whatever memory is provided to it and fill it in with whatever information it has. Rolf Kalbermatter

Which could be quite some time! Zooming pictures is not a simple thing. For instance using a bilinear interpolation works quite nicely for photo-like pictures but creates terribly blurry images for vector graphics such as a LabVIEW diagram, and besides it is rather computation extensive. Other algorithmes such as resampling the picture are reasonably nice for vector graphics but produce really bad artefacts for photo images when the zoom factor is not an integer multiple. The advantage of this algorithme is the computational speed of it. Since NI does have a software package addon (IMAQ Vision) which can work very well with photographic images and has a large amount of options for zooming pictures, the need to add sophisticated zooming capabilities to the picture control is rather limited and therefore it is likely that many other more high priority features will be tackled first before this. Rolf Kalbermatter

I have not looked at your VIs but this sounds like a familiar problem. LabVIEW does so called garbage collection on any and all refnums. The way this works is that as soon as the top level VI of a hierarchy, which created somewhere a refnum by opening an object, returns to its idle state, the refnum will be deallocated. So trying to store that refnum in a global to be used in another VI later on is simply bound to fail. By invoking your initialize routine over VI server from a separate VI you get in fact this situation. Another possibility is that by opening the refnum to your manager VI and closing it afterwards you really remove the entire manager hierarchy from memory and that should cause LabVIEW also to close refnums allocated by those VIs. You will have to make probably some modifications to your architecture to create a deamon of some sorts which is both responsible to load/unload the managers and also relays the execution of those managers to the interested clients. Your deamon must be running in the background as long as you want to make use of those managers or refnum objects created by these managers. Rolf Kalbermatter

I think this is a nocando even if you digup to your armpits into LabVIEW scripting. The context help is not yet included in the LabVIEW scripting object hierarchy and the context help window directly retrieves those text informations from the internal LabVIEW resources based on an ID of the object the cursor is on. This could only be solved currently by directly going into the LabVIEW source code and add an extra hook to the context help window. Rolf Kalbermatter

This VI calls directly into LabVIEW to call an internal C function. There is absolutely nothing you could learn from this VI other than that using a Call Library Node and entering "LabVIEW" in the livrary name you can directly call all exported LabVIEW manager functions. It is also this feature NI considers secret although they did forget in the past to protect a VI or two so the secret is not anymore secret. For us non NI people this is really limited to the functions documented in the External Code Reference manual but LabVIEW exports a lot more functions although without documentation, trying to call them is a 99.99999% chance of generating access violations and having to restart LabVIEW to continue. And no, don't expect NI to document those functions, a lot are only there for historical reasons, quite a few have probably quite a lot of undesired side effects if not called in a certain context or way and last but not least they cover areas very likely to be affected in the future by adding support for new platforms and documenting them would make it almost impossible to modify them when the need arises. Rolf Kalbermatter

Not all good things come for free ;-) But if your requirements are not that complicated you could probably get away with calling a command line tool for your favorite CD burning software through the System Exec.vi. Most CD burning packages come with an executable you can call with command line parameters to make it do certain tasks such as copying one or more directories to the CD, etc. How this is done is entirely dependant on your CD burning software and you will need to refer to your manual or online documentation or research that on the manufacturers web site. Unless your time does not cost anything I would however expect the price of that Toolkit to be less expensive than to even try to get your own solution working. Rolf Kalbermatter

In the icon editor category: If you have entered text and before you select another tool use the cursor keys to move the text around pixel by pixel to make it center nicely etc.

Theoretically you could try to interface to the Microsoft Office spell checker. At some point Microsoft did document how to do this, first by calling directly into the appropriate DLLs and later by interfacing to the Active X interface of this component. I'm not sure about the current status although I would assume that they do not promote it anymore or at least expect you to go into a license agreement with royality payements to be able to do that. Besides if Active X is the only supported interface nowadays expect to run into lots of versionening issues with different spell check libraries from the different Office packages.

I think you made a significant mistake in the calculation as you did not take into account your current time zone offset. I am not entirely sure this calculation holds true either but the result of 2082840000 would be more appropriate assuming both reference dates are supposed to be GMT which in general is the right thing. If you calculate the the quotient and remainder from this number with 86400 you get a quotient of 24107 and a remainder of 0, indicating that there are indeed exactly a full number of days in between. Attached is the diagram of the VI I used to calculate that offset. This should be independent of the time zone you are in.

Well, I think it could be an interesting project, but I also think it is a project about the size of Comedi or similar. As such it will be a long time before there is something which can be used for serious applications and it always will require tinkering of some sorts to get it working on a particular system. While directly calling into the OpenCV shared libraries will probably allow you to have something working fairly fast it will proof in the long run to be disadvantagous and quite a bit of a hasslle to maintain. Last time I looked at that it seemed to me almost unavoidable to develop yet another intermediate shared library which takes on the task of translating stuff between the OpenCV environment and LabVIEW. And then you shouldn't forget that there is already IVision from http://www.hytekautomation.com. It does exactly what you are more or less trying to reinvent (though it isn't really free for professional use). This leaves even fewer people interested to spend an enormous amount of time for such a project. Most professional users will prefer to use IMAQ because it offers support, and a known communication partner to talk too. The few professional ones feeling IMAQ to be to expensive will probably go with IVIsion and then you are left with the ones doing it as a hobby or being in education and that usually turns out to be not enough to carry a project of this size and complexity (Call Library Nodes, C programming) for a longer time. Rolf Kalbermatter

The path in a Call Library Node should be fixed up by the application builder automatically when building the executable. Basically if the DLL path is absolute AND points outside of the Windows or System directory the application builder will automatically add the DLL to the support file group which gets into the data directory by default. The Call Library Nodes in the executable will be adjusted accordingly to search for the DLL in that directory first. The problem is if you use a relative path, which LabVIEW for some reasons does turn into an absolute path always but still remembers that it is relative it would seem to me. Then LabVIEW will search the directory where the VI containing the Call Library Node resides. If that doesn't bring anything it will pass the request to the OS which under Windows will search the directory of the executable asking for the DLL (e.g. the build application or labview.exe in the development system), then the Windows and System directory and last but not least any directory in the PATH environment variable for the current user. All DLLs to be found in the windows or system directory are NOT added to the application build. Rolf Kalbermatter

That's because the DLL does NOT expect a LabVIEW handle or even a pointer to such. Instead it expects a pointer to a C string. char somevar[] is equivalent to char *somevar as far as the C compiler is concerned. This is definitely a C string pointer. Configure the Call Library Node parameter accordingly and you should be fine. A LabVIEW string handle or pointer to such can only ever be used for DLLs which have been explicitedly developed to be called by LabVIEW. Rolf Kalbermatter

No, and without wanting to sound bad, I think this would mean that nobody except a LabVIEW programmer at NI might know if it is possible at all. I personally doubt it. Rolf Kalbermatter

This really depends on the version of LabVIEW you have. LabVIEW 7.0 and higher has a property FP.Behaviour which allows setting this at your whim directly. Earlier LabVIEW versions do need the Windows library, unless you have LabVIEW 6.1 and play with the ini file in ways as described in the scripting section. Rolf Kalbermatter