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

This will create trouble no matter what. An USB device without vendor ID and product ID can't be enumerated by the USB subsystem and consequently won't be visible at all. There is really no way you can trick LabVIEW or other software into seeing such a device without completely writing a kernel device driver to replace the OS provided USB handling. And writing kernel device drivers is a task you for sure don't want to get into. Try to read into the USB spec and what is necessary on your embedded controller to properly implement a basic USB handling. Most embedded controllers with built in USB port come with example source code how to implement some kind of proper USB device type. For not to fast communication the emulation of a HID (Human Interface Device) interface will be usually the simplest method, since you won't need to implement any device driver on the OS side. For faster communication you may need to resolve to a raw USB data stream device and in that case you either need to write a device driver on the computer side or use VISA control to create an according VISA device interface. For raw devices it won't be trivial as there are much less source code examples for embedded controller firmware to do this, as well as the need to fiddle on the computer side with the device interface programming. For VISA there are a few interesting application and technical notes on www.ni.com, how to go about this. Rolf Kalbermatter

The newest LVZIP package on OpenG, which is to be released shortly does contain the CRC32 algorithme and makes it available as a user accessible function. It's implementation is in the underlying shared library and is used to calculate the CRC for the generated ZIP files. Currently it already works for Windows and Linux86 and we are waiting for a compilation of the shared library for Mac OS X, which should be done shortly, at which time the package will be officially released. LabVIEW for Windows and Linux users familiar with sourceforge can get the current CVS version from LVZIP @ sourceforge in the "source"directory to check it out. Rolf Kalbermatter

Just as Michael said, if it is an USB memory stick Windows will already install a default driver for it to make it appear as an additional drive. VISA can only access USB devices for which no other driver has been installed yet. If any other driver claims a device already, VISA backs off and rightly so, as accessing hardware from two different drivers at the same time is looking for big trouble. Rolf Kalbermatter

Oops this was meant to be a reply to the previous message. Rolf Kalbermatter

That would be a little strange it seems. Also you should consider that Hyperterminal actually adds a carriage return/line feed automatically to every line (after all you pressed the return key to tell it to send the string and the return key at least under DOS/Windows is equivalent to carriage return+line feed). Rolf Kalbermatter

Basically LabVIEW can handle 100 of loops in parallel, and does this with an amazing grace. The only thing you have to watch out is making sure that they are not free running, meaning that in each of them there is at some point an asynchronous function to limit its speed to that necessary for the task. Asynchronous nodes can be a number of different ones, the obvious ones being "Wait ms", "Wait until next multiple ms", and "Wait on Occurrence" but also the event structure itself. Also VISA or TCP functions and other ones with timeout input can be seen as asynchronous too in most cases, sometimes it is an option you need to enable on them (VISA). The only reason not to use to many loops is that you need to somehow manage them in your application. They need to be started at some point, maybe you need to have some synchronization at certain points, although they run completely asynchronous for the rest. At last but not least they all need to be told to stop gracefully somehow when the user decides to close the application. This adds overhead to your programming and also makes the application usually more difficult to understand, and with that in most cases also somewhat (and sometimes a lot) more difficult to debug. An architecture I have found to be very powerful for multi loop applications is to have each use its own queue as command input. This queue is polled inside the loop and decides the next step to execute in its case structure, really resembling a normal state machine. With some utility VIs you write, you can now send from anywhere in your application specific commands to a specific loop/state machine. You need to be careful however to design the loops and their functionality in advance and remember to adhere to this design at all times. Once you start to mix functionality in between loops in the heat of your development work, you really can end up with an application even you can't understand yourself anymore, not to talk about debugging and maintaining it later on, and even worse having someone else have to debug it! Rolf Kalbermatter

And it clutters those popup menus with so many items that normal working in LabVIEW with them is almost impossible. Rolf Kalbermatter

You seem to think we have millions of years at our hands ;-). Honestly, just do an ASCII string search on the LabVIEW executable. Unix has nice tools for that such as grep! Rolf Kalbermatter

It is nice to look at what you get by this if you have a lot of time at your hands! I haven't yet really found many reasons to actually use it, especially because use of this for production apps might be not such a good idea. As it is all about undocumented stuff really, NI is free to change this functionality at any time, by changing data types, behaviour, or removing the functionality for whatever reason and it won't be mentioned in the upgrade notes at all, so you can end up with some bad surprises when you need to upgrade your app to the next LabVIEW version. Rolf Kalbermatter

No, it isn't from a VI without password. I created it myself. Is that legit? Me thinks so!

If the C code has Endianess problems in itself I wouldn't trust it at all. It would indicate that the code was developed rather in trial and error methods, than by clearly understanding what the algorithme should do. Rolf Kalbermatter

Possibly one more CRC algorithme is in the lvzip package in the OpenG Toolkit. It is used to calculate a 16 bit CCITT CRC for the implementation of the Mac Binary format. Not sure about the correctness in terms of CRC theory of this but it seems to do, what the Mac Binary format requires, whatever that is. Other CRC algorithmes might be found on the Info-LabVIEW archives http://www.info-labview.org/the-archives Rolf Kalbermatter