Rolf Kalbermatter

QUOTE (zythum @ May 11 2009, 06:10 AM) Well the documentation link you provide says it all. If you want to access the VI from the same executable where it is embedded into, just change the path input to the Open VI Reference to a string only, containing only the VI name of the VI. This requires you to know the VI you want to execute of course. In LabVIEW >= 8 you can however not peek into an EXE or DLL anymore through VI server. So if you have some situation where you want to call a VI that is contained in an EXE or DLL that is different than the application runtime that is currently executing this will always fail. Rolf Kalbermatter

QUOTE (ShaunR @ May 10 2009, 09:19 AM) I haven't! I use a small VI that has as input the file size, the desired chunk size and the current file offset and returns the number of chars to read and the new offset. Very simple indeed. On the other hand, you can also just read until you find an error and then filter the EOF error after the loop. This is actually how you do it in C and many other applications also. You do need some indication that the file read loop needs to be terminated either by checking the current file offset to the known file length or by another mean. Since you should have an abortion on any errors in the loop anyhow, this makes the VI actually simpler as you simply abort the loop on error and then filter the EOF error out. Rolf Kalbermatter

QUOTE (ShaunR @ May 6 2009, 03:01 PM) Well, you do not get that error before you try to read PAST the end of the file. As such it is not really a pain in the ######. Reading up to and including the last Byte does not give this error at least here for me. Rolf Kalbermatter

QUOTE (angel_22 @ May 8 2009, 08:09 PM) Your requests so far are unclear at best and maybe even ambiguous. Please make an effort to explain what you want to do and how we can help you. But sending you software is certainly not an option here. NI has evaluation software to download and if you buy the LabVIEW 8.6 software you get just about every Toolkit currently available as Evaluation software on the DVD. If these options are not working for you you need to take this up with your local NI sales representative. They can and will arrange special solutions for legitimate customers. Rolf Kalbermatter

QUOTE (asbo @ May 8 2009, 09:28 AM) Well C hasn't either. NULL is simply a preprocessor define that is numerically not distinguishable to 0. Modern C compilers allow some type definition with pointer constants that allows at least a compiler warning if you try to assign NULL to an integer or 0 to a pointer but that is really all. Rolf Kalbermatter

QUOTE (turbo @ May 8 2009, 10:23 AM) Not officially. There is something called Xnodes that supposedly can do that. It is undocumented except some info in the Rusty Nails subforum here on LAVA and as I have understood quite a bumpy experience to create them. If you really are VERY VERY much inclined you can try that but it is likely yu loose interest long before you get something really nice and shiny . I haven't tried but it seems like a frustrating exercise to me. Rolf Kalbermatter

QUOTE (Antoine Châlons @ May 8 2009, 05:44 AM) I just had a short look at it. Seems it stores the information in hidden files in the system directory and there seems to be some encryption used. Since the functionality is VI based there is some possibility by a LabVIEW freak to actually replace the two or three main VIs provided by this tool and put inside the executable. Name Mangling at build time of your executable would be one possibility to complicate this to the point where it is unfeasible to work for anyone but the most determined hacker. Is it a good idea? Well I'm not a fan of software activation at all. Does it work? Most likely for almost all average users of your software. Is it worth it? The cost of the tool is certainly not a problem. The cost for maintenance however will be not negligible. You will have to build it in your app, make sure to maintain the correct keys and provide a prompt and fast service to your customers to provide them with the keys to unlock your software. Don't underestimate this last one. Rolf Kalbermatter

QUOTE (Götz Becker @ May 8 2009, 03:20 AM) Well 2 to 3 minutes sound quite bad. I did recently a project on an cFP-2020 controller (77MHz RT controller) and while it takes some time to deploy it was less than 3 minutes for sure. There were a few problems on that system that made it take up more time than I had suspected but the deployment was not the big factor on it. 1) one was that the source code debugger sometimes caused the controller to die completely when single stepping through the code. This is a known problem with the used LV 8.2.1 version but an upgrade was for other reasons not desirable. 2) Enabling VI Server on the controller made the system grind to a crawl so it was not able to do its task. I had to integrate all the parameter downloads into the controller into my already existing TCP/IP server instead of just remotely call the according VIs. 3) As the system integrated more and more functionality I had to find out that normal while loops are a bad thing on a real time controller. It worked perfectly and blazingly fast on my notebook system but started to slow down on the controller. Replacing all long running loops with timed loops made the system fully responsive again. 4) last but not least but this was not because of the LabVIEW environment or real time nature, but because of the customer application: It had been a monolithic application running on a desktop system before, with countless global variables scattered throughout the controller part and the user interface part influencing each other back and forth. When calculating the needed development time I had vastly underestimated the time needed to separate this more or less cleanly into a user interface application running on the desktop machine, and an independant controller application running on the RT controller. All in all I guess the time needed to do this would have been not less than writing the whole application from scratch again, but the LabVIEW diagram was unfortunately more or less all that was there in terms of documentation of the existing system and its interaction between the different instruments and IOs. Your 3 to 10 times development overhead is definitly way to overestimated. There is some extra time to find out about the specific details of the RT system and the used hardware but not that much. I would really recommend to start with a good system design that works on your local desktop too and then port the controller part to the RT hardware. This should be quite a simple step considering that LabVIEW on a RT system is really quite like on the normal Desktop. An interesting starting point might be also the NI System References Designs, specifically for RT and HMI applications http://zone.ni.com/devzone/fn/p/sn/n23:1.7489,n24:RefDesigns. I've been using my own system reference design from earlier projects which have the advantage that I have the complete source code of every part of the system but the Reference Designs have some good ideas and even components you can take into your applications. Rolf Kalbermatter

QUOTE (Gavin Burnell @ May 7 2009, 02:33 PM) Actually its a bit more flexible than that I think. However there are for sure difficulties. Rolf Kalbermatter

QUOTE (shoneill @ May 7 2009, 09:50 AM) Just a quick and dirty example. I didn't try to get around having to supply a valid path to the method note. Download File:post-349-1241721479.zip It's LV 8.0 because although the node is there, it returns an unimplemented error in 7.1. (04/20/2014rk, the original link got lost in an earlier LAVAG server crash) Attached is a more user friendly version of that VI. It uses the OpenG file library to create a temporary file name and makes the turnaround through a disk file in LabVIEW versions prior to 8.0. VISRV Create VI from Binary Buffer.vi

QUOTE (neBulus @ May 7 2009, 07:45 AM) In newer versions of LabVIEW the need to save the VI to disk would not even be necessary since you can create an in memory VI object just from the binary stream using private methods. Rolf Kalbermatter

QUOTE (Cool-LV @ May 6 2009, 01:14 AM) It is a combination of knowledge gained from some investigations of my own, various infos picked up from different discussions here and on the NI discussion forums, talks with some people who did probably know more, and some combinatorics. Rolf Kalbermatter

QUOTE (drake27 @ May 4 2009, 01:13 AM) There isn't a common way to note the author of a VI. Some place a comment in the diagram, others on the front panel, others yet again on the VI description and last but not least there is the VI Property "History.Entire Text" that returns the names and comments of all the changes made to the VI, IF and only IF the user had this feature enabled, which most don't since it is a pain in the ######. In general a lot of VIs do not even contain information about the author at all. Rolf Kalbermatter

QUOTE (deniz @ May 1 2009, 10:14 AM) The LLB is simply an additional hierarchy level in the path to the VI and has absolutely nothing to do with your problem here. You have some problem in how you call those VIs and/or when, but the fact that it is in an LLB changes nothing, except maybe if the VI assumes internally that it can write to a file in the same directory as where it resides itself, but from what you describe it is not clear if that might be a problem here. I also don't understand why you are using the Invoke Node instead of just simply putting the icon into the diagram. Usually condensing down everything into a simple example that you can upload here will help much more than 10 pages of hard to understand explanations of what you think you might be doing. Rolf Kalbermatter

QUOTE (santi122 @ Apr 30 2009, 01:28 AM) You can even keep the error wire wired to the TCP Close function. All Close functions in LabVIEW "should" (and usually do) close the refnum they are given, independant of the error in. There were a few LabVIEW versions in the past where one or the other did have a bug and did not properly do so but that was usually fixed very quickly. Rolf Kalbermatter

QUOTE (newTOlabview @ Apr 30 2009, 07:51 AM) I would hope that the NI people have actually done something between these versions other than just bumping up the version number, don't you agree? Rolf Kalbermatter

QUOTE (stevea1973 @ May 2 2009, 09:43 PM) No LabVIEW has to this point no official Unicode support. You can make it work sort of by adding an token to the INI file but it is still not full support for Unicode strings in all LabVIEW strings. But there is a LabVIEW VI library unicode.llb at both on the NI site and also here posted as attachment to some posts (Google is your friend ), that calls into the MultiByteToWideChar and WideCharToMultiByte Windows APIs to do the translation between the LabVIEW MultiByte encoding and Unicode 16Bit encoding. Rolf Kalbermatter

QUOTE (Antoine Châlons @ Apr 29 2009, 10:03 AM) But this returns always the same information for a VI????? What would that be good for? Rolf Kalbermatter

QUOTE (candidus @ Apr 28 2009, 06:36 AM) I think first of all that this is not even doing what you think it does or want it to do. The value of an object refnum is the refnum itself (a 32 bit identifier that identifies the object in the current LabVIEw context), not the data the object contains so what you try to do is assigning the refnum to itself really. Now why the flattened variant of the refnum doesn't convert (unvariant) easily to the refnum again I'm not sure but it may have to do with the fact that a variant does not define the exact datatype as strictly as this function expects. Variants are very dynamic and can in fact represent the same data logically in different ways with different levels of type containement. You would have to analyze the typedescriptor that is returned from the Flatten to String function and compare it with the flattened typedescriptor of the newly created variant to see if there is something special. But considering that this does anyhow not what you want I really wonder if you want to spend more time on this. Rolf Kalbermatter

QUOTE (LVBeginner @ Apr 27 2009, 09:54 AM) Well I can't even access it so I have no idea what it looks like, or what it does. I don't even know that it exists for real when going there with my webbrowser. Rolf Kalbermatter

QUOTE (LVBeginner @ Apr 27 2009, 07:29 AM) And what the heck is hermes??????????????????????????????????????? Rolf Kalbermatter

QUOTE (manojba @ Apr 27 2009, 01:48 AM) If the runtime engine is already installed on the system you can usually just copy the build directory from the application builder step to that machine. But you will need to install the runtime engine no matter what. Up to version 5.1 it was very easy to just copy everything to another machine, drop in the lvrt.dll file from the runtime engine directory alongside the exe et voila. But LabVIEW has since evolved and added a lot of features that depend on additional components being installed on a machine. Those components get installed together with the runtime engine. With LabVIEW 6 and 7 it was still possible to do such a distribution to some extend but it was a lot more trial and error which files you needed to copy from the runtime engine directory into your application directory to make it self contained. lvrt.dll alone definitly is not enough anymore and things like Advanced Analysis functions won't work since LabVIEW 7.1, since they make almost all use of the Intel Math Kernel Library from that version on and that is an external component that needs to be installed on a system in order for the LabVIEW system to find it. With LabVIEW 8.x I have not attempted to do self contained applications so far and do not intend to spend any time in doing so. The whole LabVIEW runtime universe got in the meantime so complicated and interconnected that I see no point in spending time to figure out everything just to avoid having to run an installer application. Rolf Kalbermatter

QUOTE (crossrulz @ Apr 22 2009, 01:33 PM) I think you mix up ordered and sorted. The term ordered means in my book really that there is a certain distinct ordering to the elements which there is through the array index, just as in a cluster through the element order. That does probably not mean that the elements are sorted at all in ascending, descending or whatever else order But then I might be wrong here too and they are in fact saying that arrays are not sorted with that statement and then answer E would be right according to the strange multiple choice system that in the US seems so common. It's just not what in programming terminology is usually meant by the term ordered. Rolf Kalbermatter

QUOTE (Yair @ Apr 24 2009, 03:39 AM) Well cross linking probably isn't the issue here as the Clipboard resides in the global LabVIEW context wheras each project has its own context. I think that Yair has it right that it is a side effect from the project maintaining links to all VIs that it has opened somewhere and that includes VIs placed in the clipboard. On closing of the project all such VIs get closed too. Is it a bug? Well strictly speaking I would say no. Could it be made to make an exemption in the case of clipboard code? I have really no idea. At first glance it would seem possible but I might just as well oversee a big pitfall in doing so. Rolf Kalbermatter

QUOTE (TobyD @ Apr 7 2009, 01:22 PM) I think you are right but that might have other implications somewhere they tried to fix by ordering the operations like this. With such things it is often very hard to fix something without breaking something else, and even harder to think of possibilities what might break by the fix. Rolf Kalbermatter