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

Well, on Windows you are in fact right most of the time. DOS commands are something invoked and quitting almost instantly. However on Unix it is very common to have a tool (just think about putty for instance, which you start and let do the work of establishing a secure transport layer and also maintaining it.) Now with redirected standard IO this is very simple. Start up the tool, tell it through the redirected standard input the commands to connect and login to the remote system, monitor the redirected standard output for the responses of the program and then start to communicate across the communication channel provided by this tool through the same redirected standard IO channels. At the end send it the command to close down, et voila. No need to include a secure socket communication library into your program or under Windows find out how to call the often not so well documented APIs through many Call Library Nodes if they are provided with the desired secure protocl at all. With Windows you can also do programmed standard IO redirection for invoked command line tools, but to do so is quite hard (and usually wouldn't work for GUI programs since they do at most times not handle standard IO at all). So it is seldom used but it can be useful nevertheless. Turtoise CVS uses this for instance to talk to the CVS client which does the actual CVS work, since the CVS client is really a command line tool. Rewriting the CVS client as a DLL would have been possible, but that would create a second code base which has to be thoroughly tested again, while the command line tool has been tested in years of operation already. So while it is rather esoteric to intercept standard IO on Windows at runtime of a command line tool it is possible, albeit with difficulties, and at times useful. Rolf Kalbermatter

Well, legally you can of course sell it. Some software vendors would like their users that they can not, but it is a product you have paid for and you can sell to others, provided that you do not retain any copies of any material contained in the package. After all you would have sold that package to your client too, wouldn't you? First thing to do would be to contact NI if there is a chance that they may take it back. If you have a good relationship with your local sales rep this should not be a big problem, but don't wait to long. They have limits how long they may take back stuff and they will charge you a restocking fee of some percentage. You could try to post a message here in the appropriate forum and hope that someone will be interested in this. Keep the announcement brief and don't spam every single LabVIEW related mailing list and forum repeatedly with this. If that all fails you could always go to ebay and try to sell it there. Maybe that would be even better than trying to sell it on a forum like this. Rolf Kalbermatter

Oh, well! Probably not for me. I'm to old to try to learn to handle such a beast. I can get knots in my fingers by using a three button mouse with scroll wheel already. Rolf Kalbermatter

Basically you need to redirect the standard input/output of the process to some IO channels and intercept them. NI has done this for the Unix variants of LabVIEW with the VI Open System Command Pipe or similarly named VI. On Unix this is quite simple as it is the standard way of doing such business. Windows is a lot more involved. The concept of standard IO is basically only added later to the DOS environment in a somewhat complicated way and porting that to the emulated DOS environment in Windows made everything even more complicated. I have started some work on OpenG on a module called pipe which is supposed to execute a program and redirect its standard IO to Windows pipes which would allow to write to the program standard input and read from its standard output. This of course won't work for normal Windows applications as they have usually no standard IO at all but rather use a GUI for interaction with the user. The current state of the pipe module on OpenG is still a work in progress. It does show how it is supposed to work but there are still problems and crashes with it. At the moment I have not enough time to spend on this nor enough motivation but if anyone with some serious C programming knowledge wants to look into this, I would think this to be a good starting point. The module is located at http://cvs.sourceforge.net/viewcvs.py/opengtoolkit/pipe/. Other than spending the time to make this work I would guess that only the mentioned ActiveX component would currently give a working solution. Rolf Kalbermatter

For such things, you best look at msdn.microsoft.com. The particular function is implemented by odbccp32.dll. and therfore should be easy to be called directly from within LabVIEW through the Call Library Node. Rolf Kalbermatter

Well, I would like to see that mouse with 10 buttons ;-) Honestly though, just as you have Key Up and Key Down events on VI level (posted on any key pressed) you also have Mouse Down and Mouse Up on the VI level and not just a control level. Rolf Kalbermatter

Each!!! They localized the scripting too! Rolf Kalbermatter

Well, it appears that this is a PCI board. The easiest way to go about this is installing the Windows drivers (I assume you use Widnows here) from Arcom and then using the Call Library Node, call into the Arcom user DLL. This will require from you some basic programming knowledge about C or similar programming. There are several documents on the NI site about how to call external code in LabVIEW using the Call Library Node which should help you understand the details. NI-MAX won't be of any help here. It is the NI tool to manage NI hardware and has no knowledge whatsever over 3rd party plugin hardware at all. Using an NI board of course would have been a little easier here, but you can make it work with your hardware as well, albeit it will take some more time and work from you. Rolf Kalbermatter

Modems usually don't really have any tone detection built in. They don't need that as the tone detection is done by the exchange system from the network provider and that system routes the connection based on this information to the other side (in this case also a modem). Once the modem picks up the line the dialing from the remote side has already been finished. NI had an example for a touch tone detector using their DAQ cards and a LabVIEW program. As for detectiong the ring signal, that is an option you have to enable in the modem by sending it some command. Another command will enable auto pickup by the modem on the ring signal and you can usually set the numbert of ring tones the modem should wait before automatically picking up the line. What command to use you can find in the documentation for your modem. The modem actually will activate the RI line on the serial port and using VISA you can regularly poll that signal to see if the ring signal has been detected too. When set to auto pickup, the modem will attempt to establish a connection with the remote side (if that is also a modem) and inform you of this by sending strings over the serial line. Rolf Kalbermatter

I'm afraid you don't. And thinking about it I can see why. How do you suppose should you define the different possible events you could set? Of course you could do it with strings but that is very error prone and hard to implement in the scripting engine too, as it would need to implement a state dependant (depending on the actual VI the names of the controls will change) parser and then some more. It is likely that there will be something of some sort in a futuure version but at the moment it would seem you can't do that. Rolf Kalbermatter

As far as I can say, these functions do absolutely nothing in current LabVIEW versions. I'm not sure if they are remainders of the old style memory manager in Windows 3.1 or if they were plans to add functionality which never made it into the code. Basically many of the memory management ideas in LabVIEW are not so interesting with modern OSes but were absolutely mandatory when LabVIEW was running on old MacOS and 32bit Windows DOS extenders for 16bit Windows 3.1. While some of this got removed later on as support for those platforms was dropped the fundamental architecture couldn't be changed withoug breaking lots and lots of already existing applications. Rolf Kalbermatter

This won't work. Some of the functionality needed for this is not available in LabVIEW 6.1. More correctly it is there but returns an "unimplemented" error code. Rolf Kalbermatter

1) I don't think LabVIEW has a hard 1GB limit. But it has its own memory manager layer above the OS memory functions and works with two so called memory zones from which it allocates memory. The DS (data space) zone is the memory LabVIEW uses for all diagram data and the AZ (application zone) is used for internal structures and variables. What is most probably the problem here is that the available memory is split into these two zones at startup and when you try to create your array LabVIEWs memory manager can't find a big enough block of free continous memory in the DS heap for this array. 2) There is probably not much you can do to influence the way LabVIEW manages its internal memory allocation. 3) This is a possibilty but you can't allocate memory in a DLL using standard OS memory allocaters and hand that memory to LabVIEW to work on it as if it would be its own data. LabVIEW can only work with memory allocated through its DSNewPtr/Handle functions. What you could do though is to not only implement the allocation and deallocation in your external DLL but also some accessor fucntions. Still what you want to do is basically at the outmost limit of what Windows can allow any application to do, and that assumes a machine which is not doing anything else, does not have hundreds of services running, no background tasks, a lean OS as much as possible (no unnecessary drivers and such) and last but not least a very detailed control of your memory, something LabVIEW is not really giving you easily. Even if your application would be entirely written in C and you would be an expert in memory handling you would basically scratch the absolute limits of 32bit Windows. Under 32bit Linux you would have a little more leeway as there you can configure the kernel to allow an application to have control over up to 3GB memory, but not every application can handle that (Those that assume 32bit integers for their address offsets instead of unsigned integers and I have reasons to believe that LabVIEW might trip over this too). I do think that the 1.8 GB limit you see in your C application is actually not limited by the OS itself. The OS is mapped into the the upper 2GB address space for an application, if I remember correctly. But your C application also needs some space for management and such of itself. Rolf Kalbermatter