Rolf Kalbermatter

QUOTE (jzoller @ Feb 20 2009, 02:19 PM) Yes I don't think there is any way .Net could call back into LabVIEW to let it know that it has autodisposed a refnum. But then they might want to do that for their Visual Basic environment so maybe, but I doubt it would be officially documented. QUOTE My tests were very simple: create a lot of sub-refs, then attempt to orphan them by closing the top level without closing the sub-refs. Repeat a few thousand times. Monitoring memory while this happens doesn't show any particular increase. Unless .Net can call back to LabVIEW to let it know about the the disposal of the objects there would need to be some memory allocation for the LabVIEW .Net refnum, as long as the returned object is not static. So maybe you tried with something that is static, meaning it always returns the same object and does not instantiate them. I believe LabVIEW knows about if an .Net object is static and might handle it differently than normally instantiated objects. Rolf Kalbermatter

QUOTE (crelf @ Feb 20 2009, 05:49 PM) No way. They exist since before the Picture control was released. But I guess the field edit option has a redrawing problem when dealing with transparent background. Of course deep down there is C code and to enable editing of the field they probably do use the trick of creating a temporary text entry field but fail to account for the case where the table background is transparent and simply copy the table background to the edit control in all cases, which would be certainly desired behavior for non transparent backgrounds. Rolf Kalbermatter

QUOTE (hari001 @ Feb 21 2009, 01:40 AM) http://msdn.microsoft.com' rel='nofollow' target="_blank">MSDN is your friend for detailed information about specific .Net functionality. For learning how to program it I would recommend you to get a good book about it from publishers like McGrawHill, Prentice-Hall or similar. Rolf Kalbermatter

QUOTE (bmoyer @ Feb 20 2009, 08:02 AM) Well the VIs are there in the executable embedded. But they are all broken because they try to load the NI Vision DLL and that gets only installed by the NI Vision runtime (or the Development Module but that is here not of interest). Rolf Kalbermatter

QUOTE (Mark Yedinak @ Feb 20 2009, 11:24 AM) LabVIEW offers no such access for sure. You could try to use netsh command line tool available in 32 Bit Windows installations. something like this executed with System Exec should work: netsh interface ip set address "Local Area Connection" static <local address> <subnet> <gateway> 1 netsh interface ip set dns "Local Area Connection" static <dns server address> primary netsh interface ip delete dns "Local Area Connection" all netsh interface ip set address "Local Area Connection" dhcp netsh interface ip set dns "Local Area Connection" dhcp Local Area Connection is the name of your network interface as Visible in the Network Connections. Rolf Kalbermatter

QUOTE (neBulus @ Jan 22 2009, 09:35 AM) There are more than a handful of patents that cover LabVIEW. Some quite new and some quite old. One of the first patents issued for LabVIEW run out one or two years ago but NI applied for extension and it was granted. QUOTE Keeping Scripting limited NI can maintain its control over enhancements to LV and force anyone attempting to make a better version of LV (LV writtien in LV?) they will have to work for it. I think this is one valid and actual reason they do not feel like opening it up completely. Note there seem to be people with access to it outside NI, but one needs to have a very compelling reason for that. Another one is that it has still quite a few sharp edges and trap falls. Also it does often not seem to be engineered in any specific way but sometimes looks more like ad-hoc methods and properties sprinkled across the object hierarchy of LabVIEW like it got added whenever an internal tool developer found a new hook he needed to create the next LabVIEW tool feature or addon. Sometimes obvious methods are missing that seem logical in conjunction with others that do exist. Not in the sense that one requires the other but more in why implement a method for a specific object but not for others where it does make just as much sense. Also I have a few times gone into it to solve a specific problem looking and searching for the right methods and properties only to find out that the key method threw a not supported error. Yes going to the next LabVIEW version often remedies that error but at the same time things tend to break regularly when upgrading scripting code to a new LabVIEW version. QUOTE (neBulus @ Jan 23 2009, 07:13 AM) I'll add an arguement for scripting I have an app that uses SCRAMNet and maps 2 Meg of memory for up to about 50 devices. This mapping is documented in a standard form. The mapping can change when engineerings decides it needs re-mapped. It took two developers 3 days to re-map the data fields the last time there was a major change. I wrote Script that was capable of redfining the clusters associated with the mapping and it worked on machine at home. At work it gave me an insane object error while doing the demo for my boss.... I abandoned scripting. This sounds more like an argument against releasing scripting right now. But a more realistic solution would be to write a flexible driver in the ways of Tag based addressing, where you do use the Device Names/Tag Names in your LabVIEW code and on start up load that list into a Vi that can do the TagName<->MemoryAdress translation. It's a bit of work to do that in a good way but hardly more than writing a tool that can read your address list and change all the VI code using scripting. Rolf Kalbermatter

QUOTE (Ton @ Jan 22 2009, 01:58 PM) How could this work? It does not know in any way for which VI it should open the property dialog? 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