Rolf Kalbermatter

The only option would be to create an array of clusters with one array in them. However that is a rather inefficient way for LabVIEW to store data. If your arrays can get large expect a serious slow down of your application. Also wiring such data structures can get rather messy very fast since you need to have all those Index Array, Unbundle, Bundle and Replace Array nodes all over the place. You probably would be best of rethinking your strategy of storing the data if your arrays can get larger than a few 100 elements. Rolf Kalbermatter

While LabVIEW only opened 1 thread per execution system before version 7.0 it does in version 7.0 and higher open 4 threads for each execution system except the UI system. And that means that LabVIEW will switch to other threads when one is tied up by an external call to a reentrant DLL, reentrant CIN or an Automation server. The problem with Active X is a different one. First Active X can either be a control or an Automation server and sometimes both. A control is placed in the Active X container and inherently opened by this control. A control executes ALWAYS any method and property node in the UI thread for safety reasons. An Automation server is always opened explicitedly through the Automation Open function and does not incoporate a user interface as far as LabVIEW is concerned. Those nodes CAN be called in the actual thread but only if the Automation server is marked as multithreading safe. Most Automation servers however and almost all Active X controls require Apartement threading which means the Active X control or automation server must always be entered from the same thread to work properly. In LabVIEW 7.x this is a problem as LabVIEW might enter into an Automation method or node from any of the 4 threads assigned to an execution system and if you even happen to manually assign different execution systems to different VIs, calling methods or property nodes of the same Automation server control, LabVIEW even in version 6.x has absolutely no way to avoid disaster. So LabVIEW seems to call those Automation servers from the UI thread too which is the only safe thread system to guarantee what the Automation server object told LabVIEW it would require. Solutions are: Since only the UI thread is really locked the rest of LabVIEW diagrams will actually continue to execute. No updates on the user interface will occur though and calls to non reentrant CINs and DLLs will also block here as they are also forced to execute in the UI thread. So the processing of your application really doesn't need to be affected unless you set front some panel controls to update synchronously for whatever reason as that will force the diagram to wait until the UI can be updated. IMO1: employing a hardware dongle protection will cost you more money and user credit than it can ever return in additional sales for typical LabVIEW applications. You really need to sell 1000s of copies of an application to even remotely justify use of dongles. IMO2: Using Active X for this kind of thing is the worst choice one can do. It is a very complicated technique which adds an extra layer of point of failure you will have to support in your future users environment. And believe me end user support for dongle protected applications is always a very significant part of your support cost. If I would use dongles, which I probably never will, I would simply call into the DLL provided by the dongle manufacturer using the Call Library Node. This adds as little complication to the entire system as is possible and will minimise your support significantly. Rolf Kalbermatter

It depends on your LabVIEW version. Inport an Outport since LabVIEW 7.0 can also run on a NT based system. Before LabVIEW 7.0 you had to install an accesshw.zip library you could download from the NI Developer Exchange. You might also want to try the portIO library from OpenG. You can download it using the OpenG Commander. Rolf Kalbermatter

Greg McKaskle, yes the famous one, has mentioned on InfoLabVIEW some time ago that he has a string based math library which can work with arbitrary size of numbers. Since it is string based I would guess it is not for performance junkies, but it has no other limitation in number format than what the computer can provide on memory. I think he offered this library to interested people and he may even have put it up on the Developer Exchange at some point but I'm not sure about this last point. Rolf Kalbermatter

Under modern OSes you do not deal with allocating and configuring DMA channels on your own anymore. The problem is likely that different DAQ boards have different numbers of DMA channels built in. Basically the more expensive ones have more DMA channels. Timed analog input as well as timed analog output requires usually a DMA channel. There are some boards where a missing DMA channel can be substituted by Interrupts but they can't get the data as fast into the computer and are a much higher burden to the CPU, than if DMA could be used. Most likely you have a low cost DAQ board with only one DMA channel and therefore you get into trouble trying to do timed ananlog input and output at the same time. Maybe that the people from National Instruments technical support can help you with your particular board to get one or the other operation use interrupts instead. Rolf Kalbermatter

I agree too with this. Opening a dialog with a string control set to have the keyfocus is a very universal way. The user can have a barcode scanner attached through a keyboard wedge and just use that (configure the barcode scanner to append a carriage return to each barcode send and then check for that to autodismiss the dialog) or if there is no barcode scanner present for whatever reason he can type in the ID over his keyboard and press the OK button to close the dialog If you really need to do background barcode scanner input this is usually done through a serial port barcode scanner (or with the new USB scanners through a driver which installs as serial port driver instead of plugging into the system keyboard queue). These barcode scanners are typically a little more expensive as they are not sold in the same numbers. Rolf Kalbermatter

You do have a little problem here. The actual control label information is stored in a different place than the data a control contains. Just because you find the word "password" in the binary data, does not mean that the actual default password data is directly adjecent to this string. In fact it is not. LabVIEW stores its files in a resource format very similar to the MacOS resources. That while a logical format, separates different aspects of a VI in seemingly unrelated areas in the file. So the fact that you see a password string in a file would indicate that you might try to search any other string to try to figure out which of them could be a password but it will not show you easily which of the numerous strings in a VI file is the password. Of course, why would you store a password in a VI? Passwords are to be chosen by a user and remembered by those users. Storing them anywhere basically makes passwords quite useless anyhow and you could simply forget about the hassles altogether for everyones benefit. All my VIs which contain a password control would not give you any password at all. Their default data is an empty string and it is meant to be a parameter passed from higher level functions and ultimately coming from the user itself. Any passwords I might store in an application (usually in a config file) are stored as a one way hash such as MD5 or SHA of the original password. On verification the user enters his password and the same hash is calculated and if the calculated hash does not match the stored hash, the password was not valid and access is denied. The actual password however is never stored at all. This means that if the user forgets it not even I can get it back, but its either that or you don't need a password verification at all. Rolf Kalbermatter

Why? The only sure why that your super findings can not be stolen by anyone with bad intentions is to lock them in a safe, throw away the key and destroy any notes and software code you happen to have done during development. Once you distribute it, there will be always a way to get at that information more or less easily. So you may just as well forget the pretense to have your code securely distributed and live with it. Give me a compiled DLL and unless it is code which on puropse has been obfuscated with self modifing assembly routines, I have the complete code reverse engineered in less time than it would take to just figure out how to call diagramless VIs to get at sensitive data. Does this mean that anybody using Visual C, Borland C, Delphi or whatever does not have anything to hide in comparison to a LabVIEW developer? Cool down and see the things in respective. Rolf Kalbermatter

While this type of recursion is a nice thing to show that it can be done, it has some serious drawbacks. Invoking reentrant VIs through VI server recursively is a very time and memory intense operation. Such a recursive algorithme is ALWAYS much slower than one which does the recursion through a stack based algorithme. As long as the recursion is only a few levels deep this probably won't make a to big difference but for deep recursion it is definitely a bad choice. There are several threads about factorial VIs on NIs Developer Exchange LabVIEW forum. Some show this example but there used to be a challange at some point which showed the other aproach which can calculate !3000 without taking 100ds of MBs and half of the life of the universe to get the result. ;-) Rolf Kalbermatter

The 3D graph is an Active X control and the LabVIEW implementation of the Active X container does not support transparent or overlay mode. This is partly because ActiveX initially didn't allow for that and many controls don't support it properly anyhow. If your graphic you want to display is not to complicated you could try to draw it in the Picture Control which is a native LabVIEW control and can be overlaid as desired. Rolf Kalbermatter

Early versions of LabVIEW can make copies of data where it isn't necessary. But at least since 5.x it does not generate data copies when merely passing out a variable from a subVI to its caller. This does of course require a few clarifications: If your frontpanel is open, then LabVIEW will create a copy of the data for the internal data buffer of each control. This is logical as the control needs to maintain its own copy to be able to (re)display the data as needed. In LabVIEW 5.0 and 5.01 (and probably 6.0) where some issues where passing out arrays stored in shift registers could either create unnecessary copies or much worse under certain circumstances: reuse data from earlier loop iterations which resulted in wrong behaviour. This is however not a problem which would appear in a wrapper VI but in the actual LV2 style global itself, so creating a wrapper had no influence on this nor a worse performance. In current versions of LabVIEW passing in large arrays into subVIs to be worked on in there (and preferably through shift registers in the subVI if a loop is present) and then passing them out of the subVI again to the caller does not create data copies at all, unless absolutely unavoidable because of the data manipulation inside the subVI. So this architecture is much more performant than simply branching of from the array to be passed to a subVI for operation on that array. This is since branching a wire to be passed to a subVI will have to create a copy of the data, while by simply passing it though the subVI where no branches of the wire occur can completely reuse the original buffer. Rolf Kalbermatter

You could always select the checkbox in the File Dialog "Save a copy without updating callers". Rolf Kalbermatter

I didn't want to spoil your proudness, but I created such controls back in LabVIEW 5.1 after seeing one in an NI application. There also was some discussion including a step by step description on Info-LabVIEW back then. Rolf Kalbermatter

Hmm, I think that woul be useful with scripting only. Or what sort of other property would you want to create on a loop boundery or tunnel. Then again I wonder if NI will give access to all scriptable objects directly in such a way. This may be a little difficult to implement but then enumerating recursively through the entire diagram to get at a particular object is not very wiring friendly. Rolf Kalbermatter

Well I would guess it is your problem in the end. It might be a bug in the DLL, a misunderstanding by you how to call the DLL or maybe even a licensing problem with the DLL. Who does know, other than Adlink? Your last question: LabVIEW can work with more or less all DLLs. Problematic are Callback functions, and complex structures with embedded variable sized arrays or strings. But this is nothing you could not solve with an intelligent wrapper DLL (and some more or less advanced C programming knowledge). Rolf Kalbermatter

The real problem with this is not that NI is afraid to not sell CVI but the fact that you would have to integrate a complete C parser in LabVIEW to create such a tool. This is a very enormous, and almost undoable thing. This parser can't just work with specially crafted header files but would need to digest any possible header file out there from archane pre ANSI C header files to modern files, with support for preprocessor statements and such. In addition to be meaningful you would need to be able to pass in a whole set of settings such as DEFINEs to use when translating the preprocessor statements. NI simply has decided, that this is not worth the effort as any solution they can come up with will have some shortcomings for certain header files,or this tool would be starting to get a project of its own of the size for which many more useful features can be built into LabVIEW. Importing CVI FP panels is a much simpler task. The format is defined by NI, controlled by NI and only really created by NI tools so there are little problems with interpreting what is written in such a file. Rolf Kalbermatter

Well , the cheapest solution really is in such cases to use NI hardware. I know this sounds harsh but just checkout how much a single day of your programming time is worth and then multiplicate this with your one week estimate of creating a workable DLL interface. The other option, if buying NI hardware is not possible, would be to sit at your desk and start creating LabVIEW VIs to interface to the ADLINK DLL for that particular card. These two things would be at least my solutions and definitely in that order. Rolf Kalbermatter

While this can work and it can be done easily it is not always a good solution. What you would do is adding a function to be called by LabVIEW to set somewhere a global. In your DLL check this global periodically if you have some lengthy operation. This would be best solved with Windows events. Checkout http://msdn.microsoft.com/library/default....n_reference.asp While waiting on events does basically use 0% CPU you still have a problem that you would want to actually do something in your DLL. So you can't wait on an event for long periods of time as your abort event would be not the main task you would want to perform in your DLL function after all. This makes the use of events somewhat difficult. That said, Windows APIs often support asynchronous operation. For the ReadFile(), and WriteFile() function, which is what you would use almost always for any sort of IO, you can use the so called overlapped mode. You have to open the file or device with specific flags to enable overlapped access and pass in an event handle in a special structure to the read or write function and the function returns immediately to the caller. Then you can do other things and the function will trigger the event as soon as the operation is ready or you can abort the operation with a different call if it takes to long for your feeling. Overlapped mode in Windows is a little tricky, also because it is not very simple to debug asynchronous program code properly, but it can give you seemingly fast operation and still keep your application responsive to user interaction. Rolf Kalbermatter

This is a good advice but I wouldn't make some unrelated VI down the error stream depend on specific errors not being a real error. Instead whenever you call a function you know can create a particular error you don't want to treat as error, just create a small utility VI which looks at the error cluster and resets the error status if that particular error has been seen and hook it directly after the function which can create that error. An example of such an error would be the timeout error of the TCP Read node. In most cases this is not a real error you want to bail out from but rather an indication that there hasn't been enough (any) data and that you should retry to read in a short moment. My network communication usually works in such a way that I almost always clear the timeout error after a TCP Read. An extra indicator out on that utility VI gives me a True on timeout so that I can take apropriate action such as retrying after a short delay in the subVI or often passing it out of the subVI as extra indicator so that the higher level function can take appropriate actions (usually do some other stuff and retry later again. Rolf Kalbermatter

Since the syntax of environment variables varies between systems it might be best to directly call into platform specific APIs. On Windows this would be ExpandEnvironmentStringsA in kernel32.dll. Rolf Kalbermatter

Basically error in=TRUE means don't execute the diagram code at all. However there are a few "buts" here. Sometimes it is not smart to not do anything. Also if you have controls which correspond to indicators on the frontpanel it is usually a good idea to wire them together through the TRUE case of the error case structure. And last but not least for closing resources I almost always create the VI in such a way that it attempts to close the resource independent of the incoming error. The only thing I then do is depending on "error in" either pass out the incoming error or the error from the close function. But yes besides of the last mentioning about close functions (NI does it sometimes too in their functions but not always and not consistently) you should assume that the function does basically nothing except passing through the error cluster (and sometimes also passing input data to corresponding output data). Rolf Kalbermatter

This is the test archive Download File:post-349-1118609275.zip

Well, I'm very sorry but I didn't keep my promise of not working on the OpenG Pipe library ;-). So I have created a first, appearently working version of that library. There are many possible problems with this and I have only done limited testing but it seems to work for what I have tried. So whoever feels like trying this out, feel free. I can't promis that I can do something if it doesn't work for whatever reasons. The attachment is an OpenG package of the library. I can't seem to upload *.ogp files so I gave it a ZIP ending. It would be best to rename it to .ogp and first download OpenG Commander and install it through it. Also you should get at least the ogrsc_dynamicpalette package in that case. Alternatively you could open the file with any ZIP extractor tool and put the files where you want them. The second file is a ZIP file containing a test VI and an external command line program for this test. The test VI should give you some ideas how to use the VI library. Documentation is non-existent at the moment, so you should know your command line program you want to use with this and also be willing to do some trial and error. Rolf Kalbermatter Download File:post-349-1118609673.zip

What problems do you have with running this VI on LabVIEW for Linux?? IT should be all native if I'm not mistaken and therefore should work on any LabVIEW platform equally well. Rolf Kalbermatter

Of course it is possible. There is vitually nothing impossible in LabVIEW ;-) You will have to look at the Picture Control if you want to stay native. Expect this project to be a major work however. The Picture Control is like a sketchboard. You can create code in LabVIEW to draw anything in there. The problem arises if you want to let the user modify an already created drawing. You will have to map the mouse click back to the object you think the user wants to modify and figure out a way to let the user do operations on that object. The first thing is done by really maintaing the drawing as an array of clusters with each cluster being an object and all the necessary parameters in the cluster like the type of object, size, location, and so on. Every time you want to update the entire drawing you walk through this array and create a new Picture Control drawin. To find back the object which a user might have clicked at you will again walk that list and need some smart routine to find out the object best mapping to that location. Then you might have to find a way to let the user manipulate the object. Things like moving an object are obvious operations but still not all to simple. Other operations might best be handled by object specific property dialogs you popup. Rolf Kalbermatter