Rolf Kalbermatter

QUOTE (Ton @ Jan 17 2009, 06:58 AM) And still no license manager making things harder Rolf Kalbermatter

QUOTE (george seifert @ Feb 19 2009, 11:07 AM) DAQmx on VirtualPC??? VirtualPC is simply a virtual machine from Microsoft much like VmWare. I can't really believe that VirtualPC does virtualize the PC Hardware to the point that DAQmx can really work on there. Well, it seems it does work , which is quite amazing if you ask me. You say DAQmx has been installed and seems to work. How did your customer check that? Can he go into Measurement & Automation Explorere inside the VM and see the boards installed and also execute the Test Panels for them? Rolf Kalbermatter

QUOTE (Ton @ Feb 19 2009, 03:39 AM) And that even works remotely. Maybe not a good idea to do that over internet with a 100 ton press controlled by LabVIEW or some heavy motion system but for some applications it can be really good. Rolf Kalbermatter

QUOTE (jzoller @ Feb 18 2009, 04:35 PM) Not sure about .Net references but if it is anything like ActiveX then yes they would need to be closed explicitly if you do not want them to linger around in memory until you stop or close the Top Level VI in whose hierarchy the reference was created. This last one is a LabVIEw specific feature since it keeps track of all its refnums and destroys them when the Top Level VI in whose hierarchy the reference was created goes idle. When it destroys its refnum it also closes the underlying ActiveX or in this case .Net handle. Otherwise the ActiveX handles would remain in memory until the process that created them is going to terminate in which case Windows process cleanup code takes care about closing anything still left open. Rolf Kalbermatter

QUOTE (JustinThomas @ Feb 18 2009, 11:38 PM) But since the VI is in a normal case structure it will be compiled into the executable. This is exactly what the OP wanted to avoid. However I do not see the real problem. I'm frequently debugging (single stepping) into VIs called with Call by Reference and that seems to work fine. Of course both the caller and callee need to be on the local system then. Rolf Kalbermatter

QUOTE (crelf @ Feb 16 2009, 11:48 AM) Well I can't say with absolute authority that there couldn't be some method to initialize the password cache somehow, but I am not aware of any other way to get the password cache filled than by applying a new password to a VI or entering a valid password for an existing VI. Nothing else seems to work and shouldn't either. It does not make sense either so why should NI add such a thing? Rolf Kalbermatter

QUOTE (vugie @ Feb 16 2009, 10:24 AM) No but in order to fill the cache you have to apply a password to a VI through VI server. At around 100ms per execution you will wait a long time to fill that cache significantly. And I believe that if the password does not match it will not be added to the cache! So you need to apply a new password to some VI, clear it and add another one, at about 100ms for each operation Shutting down LabVIEW destroys that cache too. Rolf Kalbermatter

QUOTE (torekp @ Feb 16 2009, 07:48 AM) The only problem where you should get a not file found error is in fact when trying to open a file. So I do not see how you would have to wrap all FileIO functions. Just creating your own Create File/Open File function and using them consistently in your apps would help. Rolf Kalbermatter

QUOTE (Klompmans @ Jan 29 2009, 09:05 AM) Personally I would write an application that controls the device and also contains a TCP/IP server that can accept connections and act on specific commands on these. Is it more work than using shared variables? Maybe. Is it more flexible? for sure. Does it ease distribution of your application because you do not have to deploy the shared variable engine and the definition? You bet! Rolf Kalbermatter

QUOTE (jdunham @ Feb 13 2009, 05:01 PM) The fact that there is no typedef for error clusters wouldn't necessarily preclude changing that. They already have special case handling that allows to connect an error cluster to a Selector Node or a case structure Selector, as well as enabling the popup menu about explaining the error. This is all done on the recognition of the specific type definition (as in the type signature not what you understand as typedef on LabVIEW FP level) an error cluster has. But the issues are very complicated. You could create an error structure that allows structured exception handling, error classes and according inheritance and what else you can think of and create a monster in handling it, performance and memory footprint. And typedef or not the real difficulty is about upgrading existing code that comes not from NI. A typedef wouldn't help at all as it still would break tons of code that was crunched together by someone who had no idea about using even the limited facilities of the error cluster in a useful way. Rolf Kalbermatter

QUOTE (Vende @ Feb 12 2009, 04:47 AM) Well you usually get what you pay for. So you want free and easy, if possible without any work from you? And of course bug free and perfect too? 'QUOTE (normandinf @ Feb 12 2009, 10:42 PM) In my experience, I always saw the pixelink cameras in MAX, I just needed to change drivers. Have you installed IMAQ? I'm not sure you can see the cameras in MAX without IMAQ installed. I'm pretty sure you can't see it without at least NI-IMAQdx and the Firewire support installed (which is all part of the license required Vision Acquisition Software). So no it is not free, but yes I would call it very easy. Rolf Kalbermatter

QUOTE (austin316 @ Feb 16 2009, 02:08 AM) If the host is using adressed UDP datagrams in contrast to broadcasts, only the adressee will receive the datagram. What destination address do you see in Wireshark? Note that Wireshark uses promiscious mode to receive any datagrams and TCP packets on the network interface. This is a mode that can not be used by a regular sockets as used by LabVIEW and just about any other network software but only by tapping directly into the card driver through a filter driver. In Wireshark they use the WinPcap driver for this. Rolf Kalbermatter

QUOTE (Dan DeFriese @ Feb 14 2009, 12:48 AM) Wonder which version that was?? :-) UDP VIs used to be VIs implemented in LabVIEW calling into C code ages ago. And yes there was no seperate reference for UDP communication. But this must have been like pre 6.x! Just checked and 5.1 had those VI based UDP functions and there was no separate TCP and UDP refnum type. So either the OPs were working in 5.1 or earlier (stll a very old version for 2004 standards) or had been bitten by either a bug in the upgrade process when upgrading an old VI to a recent version or cross linked themselves something. Rolf Kalbermatter

QUOTE (Aristos Queue @ Feb 15 2009, 03:50 PM) Most likely he means an OLECHAR or BSTR string. It is basically a memory buffer that has a 32 bit character length in front followed by the actual characters (but as widechars, UTF16) but the pointer points to the first character hiding the length effectively. The problem is not the zero character at the end, in fact this layout was probably devised so that a BSTR could be still interpreted as C widechar string if one makes sure to zero terminate it. I have posted an unicode lllb on the NI forums ages ago that can also create and deal with BSTR and add it here for completeness. LabVIEW version >= 6.1 http://lavag.org/old_files/post-349-1234772122.llb'>Download File:post-349-1234772122.llb Rolf Kalbermatter

QUOTE (Ton @ Feb 13 2009, 05:33 PM) To the original poster: A string (or array) can't really be passed by value since they are always pointers. To Ton: You are certainly right. Only for strings (or array) it is actually even easier than that. No new allocation of memory or copying of data is really necessary since LabVIEW can simply pass the pointer to the data portion inside its handle to the DLL. For strings there is however one extra step. Before passing the pointer, LabVIEW resizes the string handle (but does not change its internal character count) to make sure it is one byte longer than the actual string data and then sets this extra byte to 0. Now the data portion of of the LabVIEW string handle can also be interpreted as zero terminated C string. On return from the C function, LabVIEW will scan the returned string buffer for a zero character up to the passed data length and then set the character count of the string handle to only contain the characters up to and excluding the zero character. Rolf Kalbermatter

QUOTE (menghuihantang @ Feb 13 2009, 01:43 PM) LabVIEW internally does a lot of different handling. While data is in general of course always some memory location the term by reference or by value does not apply to the diagram or front panel at all since LabVIEW uses strict data flow programming. But the Call Library Node does have a configuration dialog for a reason. Here you tell LabVIEW how the DLL function expects the data and LabVIEW will take care to pass the parameters accordingly indpendant how it uses them internally itself. If LabVIEW would simply pass data in whatever format it uses internally you would not be able to call most C functions. Rolf Kalbermatter

QUOTE (menghuihantang @ Feb 12 2009, 05:00 PM) Well didn't know that var would mean pass by pointer. Normally pass by pointer variables have the addition ByRef in VB. var means this in Pascal but maybe VB added that keyword to ease migration for Pascal users. Rolf Kalbermatter

QUOTE (Aristos Queue @ Feb 11 2009, 06:33 PM) He doesn't show the function configuration in the dialog but I strongly suspect a wrong calling convention. This will usually crash no matter what unless sometimes with functions that have no parameters at all. I agree that the parameters look right and seeing them being just integers it is hard to see how there could be anything wrong with them. The configuration of the return value never will crash unless you tell LabVIEW it is a string while it is either void or Numeric. Rolf Kalbermatter

QUOTE (nitulandia @ Feb 11 2009, 03:14 PM) Indeed. It is part of the strong name of .Net DLLs too. In order to be able to install a new version of a .Net assembly in the GAC one has to use an increasing version number. However the constructor node is strictly connected to the strong name of the assembly if available. So if you install a new version replacing the older one you have to reconnect the constructor node. This is a pita but not easy to circumvent and if one would try to circumvent it one would cause other problems when more than one version of a .Net component are installed on the same machine. I'm not aware of a good workaround for this. Placing a .Net DLL (and its dependencies) into the application directory could litigate the issue a bit at the cost of saddling you with the distribution of the .Net assemebly with your application. Rolf Kalbermatter

QUOTE (Neville D @ Feb 5 2009, 01:27 PM) VI Server on RT targets can have bad side effects. I enabled it recently on a CompactFieldpoint 2020 controller (one of the slowest there is I believe) and the whole application started to behave erratically since the processor load got so high that it could not keep up with running my normal VIs. And I had only planned to execute a VI or two remotely through VI server to send and retrieve some data. Turning VI server off and integrating that data transfer into my already existing LabVIEW TCP/IP server protocol on the controller made everything go smooth again. So if your CPU is not very powerful VI server certainly can cause problems and your timeout errors might be the reason for that. This is probably not gonna work since it would require building a new executable after every modification by the client but there is a VI library on the NI site called "System Replication" that allows downloading an executable and enabling it to be run from the host. I'm currently still experimenting wth this but it seems to work as I had hoped. Rolf Kalbermatter

QUOTE (sachsm @ Jan 21 2009, 11:00 AM) Try to save it to a version before 8.5 and you get an error that it did not exist in that version. And yes it is definitely part of the LabVIEW DSC add-on. Rolf Kalbermatter

QUOTE (Peeker @ Feb 5 2009, 06:21 AM) That is correct. SystemExec launches a process and nothing more. If you want to have DOS box behaviour you need to launch the DOS command prompt and pass the commands you want it to execute as command line parameters. Rolf Kalbermatter

QUOTE (Tomi Maila @ Feb 14 2007, 05:20 PM) I use a technique I got from my collegue who delveloped LuaVIEW. It is simple VI that sits in the root of all my project directories and on startup scans the entire subdirectory hierachy for folders having the name "unit tests". Any VI in there having a predefined connector pane that returns a boolean will be loaded and presented in a list. The UI allows to then run all tests or individual ones and the result of the run is shown. The UI also has options to directly open the front panel so that when a test indicates failure I can go and directly debug it. Very simple and trivial but quite effective. The only drawback is having to write the actual unit tests , but that is a problem every unit test framework has. Rolf Kalbermatter

QUOTE (Aristos Queue @ Jan 29 2009, 07:01 PM) While I'm not easily tending to violent actions I sure would scream hell and fire if someone did this change. The hypothetical chance to unlock someone elses VI because it uses the same password as one I know for another VI is no justification to make the password a complete useless feature . Also VIs would then need to remember that they were unlocked as otherwise you would have to reenter the password everytime after closing the diagram. OMG!!! Rolf Kalbermatter

QUOTE (mesmith @ Feb 5 2009, 02:43 PM) The chip is not everything. You can easily create a GPIB driver that works reasonably on an 8 Bit CPU. Getting a TCP/IP stack to run properly on such resource constrained hardware is quite a different challenge. That said the embedded controller nowadays even for very simple devices get to a level that has more processing power than a complete mainframe from 30 years ago and is quite likely a 32 bit CPU core too. Also the knowledge about how to implement TCP/IP (open source implementations all over) is probably getting to a level were it is easier to dig into that than getting the somehow archane and not very easy to tackle task to control a GPIB controller to work. But that is certainly a recent development. Even a few years back adding a TCP/IP connection to a device was certainly more expensive than doing that with a GPIB interface even for manufacturers that had already quite some experience with TCP/IP interfaces in their devices. Rolf Kalbermatter