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

QUOTE (jfazekas @ Jan 26 2009, 02:24 PM) Not sure about LV Class but a typedef in itself won't help. What you should try to do is passing your array in and out of VIs. Avoid branching as much as possible unless you branch of inside a structure to some non-reusing LabVIEW internal nodes such as Index Array, Array Size and similar. Bascially you should try to have the array as one wire going through your entire application. If you need to create a branch make sure it is in the same structure as the function that consumes the branch. You might branch to determine the size of the array but if you do that outside of the structre while the Array Size VI is inside a structure LabVIEW will likely create a copy. If you have loops to operate on the array create a shift register and wire the array to the left terminal wiring it from that terminal to the inside of the loop and making sure to wire it inside the loop back to the right terminal. When the loop finishes you just get the array from the right terminal and go to the next function. If you do this right LabVIEW will usually already avoid data copies even without using the Inplace Structure. In fact the Inplace Structure does not so much optimize the LabVIEW access (it does some extra optimizations) as much more enforce this type of wiring more strictly. With these techniques I have created VI libraries operating on huge multi MByte Arrays in speeds comparable what fairly optimized C algorithmes could perform even before the Inplace functions existed. Rolf Kalbermatter

QUOTE (pallen @ Jan 26 2009, 01:43 PM) Most likely a graphics driver issue. LabVIEW does direct X Windows drawing and depending on the graphics driver used this might cause such issues. Try experimenting with the graphics driver settings, such as color depth, acceleration and such. Rolf Kalbermatter

Sometimes see it too. Usually a recompile (Ctrl - run button) of the VI fixes it. But I'm not using LVGOOP so this might be another source of this problem that might not be fixed with a recompile. Rolf Kalbermatter

QUOTE (MJE @ Feb 3 2009, 11:43 PM) They would get lynched by even more folks for "dictating" the font they have to work with, even if it would be configurable and just a default setting. QUOTE (jdunham @ Feb 4 2009, 12:09 PM) Yeah, I agree. When we build our application, we make sure those fonts are in the application's "labview.ini" file, because everything looks wretched otherwise. Forget about any kind of cross-platform GUIs. It sure would have been nice for NI to have dealt with this a bit better, though I know fonts have always been a pain for them. Not just for them. Fonts are a pain whenever you have to deal with them in any software. It's already bad when you just need to make font metrics work but gets impossible if you need to allow changing them. I rather have them use their time on something useful than trying to fix something impossible. Rolf Kalbermatter