Jump to content

Rolf Kalbermatter

Members
  • Content Count

    3,049
  • Joined

  • Last visited

  • Days Won

    153

Everything posted by Rolf Kalbermatter

  1. This is the test archive Download File:post-349-1118609275.zip
  2. 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
  3. 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
  4. 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 a
  5. 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 t
  6. 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 the
  7. 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
  8. 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
  9. 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
  10. 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
  11. Each!!! They localized the scripting too! Rolf Kalbermatter
  12. 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
  13. 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 au
  14. 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
  15. 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 change
  16. 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
  17. 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
  18. 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
  19. 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 @ sourcefor
  20. 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
  21. Oops this was meant to be a reply to the previous message. Rolf Kalbermatter
  22. 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
  23. 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, sometim
  24. And it clutters those popup menus with so many items that normal working in LabVIEW with them is almost impossible. Rolf Kalbermatter
  25. 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
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.