Rolf Kalbermatter

QUOTE (Gavin Burnell @ May 17 2009, 12:29 PM) Someone probably feels very hurt at being so badly misunderstood in her intentions that were anything but self centered. Well I did learn a new word "purdy" Rolf Kalbermatter

QUOTE (hooovahh @ May 27 2009, 09:50 AM) Your list is certainly extensive and not really required by many applications. For LabVIEW 7.1 what I have found absolutely necessary in order to get a simple executable running are following files: lvapp.rsc vidialogs.rsc lvrt.dll if you use any of the 3D controls you also will need mesa.dll and some or all of the models subdirectory. If you only use simple 3D controls such as buttons you can get away with only including one or two ptc files in the models directory. Other DLLs may be required from the runtime directory depending on what functionality you are using in an executable. If you use various dialogs, lvdialog.rsc and lvstring.rsc may be quite necessary. The scripts directory is only necessary if you use one of the script nodes and then only the one dll in there you use the script interface for. visarc will be for the VISA interface object hierarchy descrptions and is only requiring startup time to build up the internal object tree if you are not using VISA at all.

Typically this is a problem with your DLL and/or how you call it. You do not say how you created the DLL (LabVIEW or C) nor how you try to call it. But a common problem is that people calling a DLL from LabVIEW using the Call Library Node do forget that in this case normal C rules apply and the automatic memory allocation management they have gotten so used to in LabVIEW does and can not work here. So they call a function to sum array a and b and hope that the DLL magically allocates array c to write the result in. Well the DLL can't do so and LabVIEW can't do so for you either as the development of the LabVIEW mind reader interface to read the programmers intentions is still in the early stages of prototyping . So what happens is that the DLL writes its results in the invalid (or to small) memory pointer that is passed to the DLL and sometimes that overwrites only non-vital data, sometimes it overwrites very vital data that will make LabVIEW crash after the fucntion returns (or destroy the VIs that you have in memory) and sometimes it happens to write to memory locations the OS knows are not valid for the current process, which will throw the exception during the fucntion call already. Review your DLL for possible out of bounds array references, make sure you call it with preallocated arrays that are long enough for all array and string output parameters and then come back with more info such as the DLL source code and test harness itself if it still fails. Rolf Kalbermatter

QUOTE (Rob Calhoun @ May 14 2009, 10:29 AM) Your assumption is mostly right. The reason it is a 64 Bit integer is not exactly because the wire needs to be a known data size at compile time since a 64 bit platform is considered a different platform and a recompile would be necessary anyhow if you go from 32 Bit to 64 Bit or vice versa. But imagine you passing this pointer to a subVI. To make this work LabVIEW would either have to create a new pointer size datatype or as it does now, always use a 64 Bit (unsigned) integer. The pointer size datatype would be cool as LabVIEW could treat it as separate type incompatible to anything else and you could in such a way avoid a user wiring pointers to integers and vice versa. But it is also a very strict notion and primitives such as add or minus would either need to be updated to accept such a datatype or you could not do pointer arithmetics (offsets) on them. And you would need to find a new wire colour, and change many other functions to support this type too, and, and, and..... Since any sane VI library developer will avoid bothering his/her library user to bother about such things by having such pointers on the top level API, the fact that the pointer sized parameter can be wired with integers is not such a big deal. The person doing the Call Library Node VIs hopefully knows what she is doing and the rest don't have to worry about that . As it is now the Call Library Node will pick for such parameters the correct 32 Bit part or the entire 64 bit part of the integer based on which platform it is running. There is no ambuguity that makes this not foolproof, since you either work with 32 Bit LabVIEW and a 32 bit DLL or 64 Bit LabVIEW and a 64 Bit DLL. Mix and match between these two is not possible and a 64 Bit DLL will always use 64 Bit pointers and the same applies of course for 32 Bit DLLs. Of course if your DLL does some nasty tricks with WOW64 and passes those none-native pointers to the caller you would need to adapt for that by NOT using the pointer sized parameter types but explicitedly selected integer sizes. But anything that is declared as pointer in the prototype, and looks, smells and sounds like a pointer will use the platform pointer size that LabVIEW is also using when you select pointer sized integer. Rolf Kalbermatter QUOTE (stevea1973 @ Apr 26 2009, 08:01 PM) There are a couple of issues really. The statement char **ch declares a pointer to a pointer, so it is wanting to manipulate the reference you have to the string, I expect labview would have a few issues with that as it may cause loss of data because you are losing a reference to whatever that wire held. I really don't know how it would interact with labview, but I'd guess it might not be nice. You actually can do that by defining it as an (pointer sized) integer passed by reference. BUT!!!!!! You need to be very careful about what you do then. First you can not access the data in that pointer directly from within LabVIEW. You either need specific functions in the DLL to return information from that pointer or need to us the unofficially well documented MoveBlock() calls to copy the information out of the pointer into LabVIEW data buffers. Second and this is important: You need in most cases to call the according function to deallocate this pointer after you are finished with it. Otherwise you create a memory leak. I say in most cases since it depends what the function really returns. If it is just the pointer to some statically allocated buffer you better don't try to deallocate it. The same applies if it returns just a copy of the pointer that was passed in as parameter and therefore got in fact allocated by the caller, here your LabVIEW diagram. In all other cases however the library will either have to export a deallocation function (most cases) or document exactly which platform API has to be used to deallocate the resource. A free() will not cut it here since that can depend on the C runtime the application or DLL was compiled with so that the application and DLL can in fact use different memory manager libraries, and pointers from either part have no meaning for the C runtime memory manager calls of the other. (Obviously they are allocated in the same process space so can be accessed from both parts but functions like realloc() and free() might crash badly if applied to pointers coming from another subsytem/DLL). Rolf Kalbermatter

First question: True Second: , with y = 1 It always amazes me to see such code snippets in someone elses program. I once had an application that was using the Select function exclusively to do just about every possible Boolean operation you can think of including AND, OR, NOT. I just can't imagine this to be easier to do than using the proper primitive instead. But maybe that is because I did actually learn Boolean Algebra in my electronics education. Rolf Kalbermatter

QUOTE (ShaunR @ May 11 2009, 05:41 PM) Which makes it probably more like XP Embedded anyhow 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