Rolf Kalbermatter

QUOTE (netta @ May 6 2008, 08:51 AM) It uses whatever the OS is able to provide and does not know the difference of physical memory or virtual memory at all since that is managed all by the OS. However there is a default limit of 2GB memory per process for all 32 bit OSes independant of the actual physical memory available. Most OSes can be switched with an option to allow the OS to give an application up to 3GB of memory but for more you do need true 64 bit OS and application support. Rolf Kalbermatter

QUOTE (kawait @ May 6 2008, 10:05 PM) Well you always have to allocate the space in the caller for C type pointers. Nothing wrong with that. In principle there is also no difference in passing a byte array or a string. Memory wise they are the same. But the way you do it now you will receive a byte array from the dll that is exactly 100 bytes long independant of how many characters the DLL filled in. The Byte Array to String function will not change anything about that so you always end up with a string of 100 characters with the desired characters in the beginning and NULL characters in the rest of the string. The Call library Node does however have special treatment for parameters that are configured to be C style string pointers. On return LabVIEW will scan the string and search for the terminating NULL character and then resize the string to only be of that size. So by moving the Byte Array to String function before the Call Library Node you do both allocate the size of it (it's a lot easier to allocate a Byte Array using Initialize Array than putting a string constant on the diagram that contains the necessary amount of spaces or whatever) and on return you actually already get the string properly resized to the real string. Please note that this resizing will only shrink the string buffer. You do need to make sure that you pass in an array that is positively and under any circumstances big enough to receive the actual string. QUOTE BTW, after I made my post here, I seemed to find out some big mistake. The explicitly call the cleanup function in my VI seemed the one which causes trouble. After I have removed the explicit call to the cleanup function my VI doesn't crash at all after almost 10 run cycles (I cant say that it wont crach though). I know it is just because I have done the cleanup of some resource too early in my DLL cleanup function and I will take further look to that. That is the difficulty! No crash does not mean it is already working perfect. It may still just destroy non-vital data that could only show up as crash when you end LabVIEW, since it tries to dealocate resources you happen to have destroyed or it may be as subtle as only visual or non-visual corruptions to your actual VIs that may trigger many days later. Rolf Kalbermatter

QUOTE (xinbadaz @ May 6 2008, 01:47 AM) This is a bug in the type library for above Active X component. That typelibrary contains a directory entry that points to the same directory as the type library itself but the help file name in there is only the file name itself and no subdirectory. It's not a LabVIEW fault at all since LabVIEW should not have to worry about the language ID of help files and accordingly not have to search in subdirectories of the expected location for that file but the typelibrary should point at the right locations directly. As to how to let LabVIEW know how to find the help file there is not so much you can do since editing the typelibrary is not really an option. I would just copy said help file to where the typelibrary says it is and be done with it or upgrade to a newer office version if I would use Excel over Active X at all. Rolf Kalbermatter

QUOTE (kawait @ May 5 2008, 09:17 PM) Lot's of questions and little hard facts to check and look at. A few comments though: 1) What I usually do is having one or more exported function to allocate resources (my DLL typically can handle multiple connections/resources) and also according functions to release those resources. All resources are also stored in a global list and on DLL_PROCESS_DETACH I check this list and deallocate anything that might still be in there. I normally never do resource allocations in DLL_ROCESS_ATTACH but instead make sure that the functions do check and if necessary allocate whatever they need at runtime only. 2) If you are positive that the types are compatible it really doesn't matter. Those nice extcode.h datatypes are for clarity for the programmer and to allow LabVIEW to define them to whatever a specific compiler may need to but in nowadays 32bit only world these are fairly consistent across compilers and plattforms. 3) Not really clear to me. But of course for parameters that need to return something to the caller you always need to pass them by reference (as pointer). You can also convert the Byte Array to a string and pass it as C string pointer directly. This has the added bonus that LabVIEW will search for the NULL terminating character on return and pass only the valid part of the string further. Never ever use DSNewPtr or any of the other *Ptr memory manager functions for DLL functions parameters that are passed from LabVIEW or returned to LabVIEW. Those parameters are either skalars, C pointers or LabVIEW data handles. For skalars there is nothing special, for pointers they have to be allocated in the caller (e.g. Initialize Array). The only parameters passed from and to LabVIEW that can be modified in terms of memory allocation are handles and for that you will need the according handle functions of the memory manager. Although for most cases I really would recommend to use NumericArrayResize whenever possible. 4) No! LabVIEW is definitly not more or less stable in calling external code routines in just about any version since 5.x or so. What you see is that in an executable the memory layout of your application is of course different so when your wrongly configured function parameters or your wrapper DLL happen to step on invalid memory (invalid in the sense that they shouldn't try to write to it nor even access it at all) they will overwrite sometimes vital LabVIEW runtime data and sometimes just some LabVIEW edit data. If overwriting LabVIEW runtime data, this sooner or later will cause big trouble. It could crash as early as when doing the writing or as late as when exiting the application since LabVIEW tries to deallocate resources that have been invalidated by the overwriting. Overwriting LabVIEW edit data or such will possibly only be detected when you happen to open for instance a front panel or diagram and try to do some modifications. It could be just some strange text somewhere or weird attributes of objects or LabVIEW could be tripping then over the non-sensical data and go belly up at that point. Rolf Kalbermatter

QUOTE (Jim Kring @ May 4 2008, 01:02 PM) Actually I do but never used it so far. Reason for me is that it is in fact still unoptimized since you first create the entire array and then build it into the really desired array although this last step is happening rather optimal. In a lot of cases I end up doing more complex algorithmes anyhow that avoid the data memory fragmentation caused by the Build Array inside the case structure altogether. Happened to help me reduce the runtime of a particular function at some point from about 50 seconds to far less than 1 second at one time. Of course writing that function took me also a bit more than the inverse proportional time of what the first approach with simple Build Array in a case structure had taken me. But considering that my customer has probably saved in this way I don't know how many hours of waiting for the calculation result since, I feel this was well invested development time and it was fun and educational too to do it. The OpenG function would likely have been only slightly slower but would have taken up temporarely more than double the memory of my approach and that was at that time not unconsiderable in relation to the available physical memory. Whenever I hear someone swear at how bad the speed of programs written in LabVIEW is I just smile and think about this. It's not that LabVIEW is slower than C in most cases or that it is that much harder to write well performing algorithmes in LabVIEW but the simple fact that it is a lot easier to write an algorithme in LabVIEW at all. Sometimes those algorithmes end up in a way that a C programmer would not even think about to do because he needs to deal with every memory allocation anyhow so is likely to look for an algorithme where he does not need do this all over in his code over and over again. But the build in feature as suggested by the OP would be even more optimal than the OpenG function although of course not as optimal as the unconditional For loop auto indexing. If I would be a LabVIEW engineer I would make that conditional auto indexing generate the same machine code as what is used for while loops. There the intermediate array is started of with some intial size and then whenever it gets to small the currently allocated size is doubled. At the end of the loop the array memory is resized to its really used size once more. This is the most optimal approach in terms of memory (re)allocations and data copying for generic situations where you do not know the finally needed size beforehand. And one last note: I wonder when there will be a patent filed by NI for exactly this . From my understanding of patents it would not be valid since this idea has been published here prior to such a patent filing but who would be going to court with this? Rolf Kalbermatter

QUOTE (MartinGreil @ May 2 2008, 10:30 AM) It would mean that every autoindexing output tunnel in a loop has an (optional) boolean. Interesting idea but Ohhhh so unintuitive! One more of those features even LabVIEW cracks would only discover by accident after years of programming. Rolf Kalbermatter

QUOTE (ragglefrock @ May 3 2008, 11:44 AM) My understanding of this is that LabVIEW does not do any optimization across VI boundaries. So Call By Reference and subVI should not make any difference. The subVI is assumed to reuse the data. If it doesn't the data is deallocated. That is why it is a good idea to wire large data always completely through a subVI (so no entering in one case and leaving only in one case but entering outside of any case and being wired through every single case frame and then to the indicator terminal outside any case again) even if you do not modify it inside the subVI. LabVIEW only knows about nodes (built in icons usually with white yellow background) if they reuses input data or allocate a copy. For nodes reusing the data the same rules apply as for subVIs but for nodes not using the input area in any way after they have finished execution LabVIEW makes sure to order execution in such a way that those nodes get executed first if no other data dependency prevents that, in order to allow saving memory copies. Rolf Kalbermatter

QUOTE (raul70 @ Apr 29 2008, 07:33 AM) One other thing I see is the command string to set the ESE and SRE registers. You seem to have them separated with a line feed only. Maybe the Keithley accepts that but it is standard usage to separate several commands in one command string with semicolons from each other. It could just as well be that the Keithley device only sees the ESE command but not the SRE command in this way. Rolf Kalbermatter

QUOTE (crelf @ Apr 30 2008, 06:58 AM) I feel completely misunderstood . I always thought to be part of the 0.3 % that understands all and everything. Rolf Kalbermatter

QUOTE (Yen @ May 2 2008, 05:30 AM) Yen I think you take it a little to literal. Critisizing the massive amount of time our western society spends consuming more or less informative or useful TV does not mean that one wants to say TV nor doing nothing is bad at all. But on the other hand a large part of TV consumation is not very productive in any way other than keeping some people of the streets (which in itself could be a welcom cause for some although not a sufficient one for me). No human can be fully active 24 hours a day without getting a burn out pretty fast. But I do believe that lots of things that should actually be done are not getting done because it is so much easier to sit on a sofa and watch some more or less stupid repetition of what has been shown 100 of times before. I can understand to some extend that someone wants to watch Big Brother once or twice to see what it is about. I can not bring up much understanding that this kind of program is being repeated times after time on I don't know how many channels since many years and people still keep watching. It's this kind of TV that makes me support many of Clay Sharky's statements. And I do believe that something has to change. And his message may help to wake up some and realize that life is not just about sitting in front of a TV screen and consumation in general and the necessary devil of work to support that, but that there is a lot more to it than that. Rolf Kalbermatter

QUOTE (Jim Kring @ May 1 2008, 11:44 AM) Nice movie and good message too. For me the text messages were however just a tiny little bit to short in duration to be comfortably read. Rolf Kalbermatter

QUOTE (Amelia @ May 1 2008, 11:13 AM) Then your splash screen takes to long to load. LabVIEW waits a few 100ms befor putting up the load dialog. This is enough to load a splash screen that does not have a to large hierarchy. Of course if you add your main VI statically into the splash screen that hierarchy needs to be loaded too before the VI can start executing. Instead you want your splash screen to start up immediately showing it's front panel and then load and start (Run) your main VI dynamically using VI server inside the diagram of your startup splash screen. Once the main VI has loaded and started by opening its frontpanel your splash screen can stop and close. Rolf Kalbermatter

QUOTE (Yuri33 @ Apr 30 2008, 02:41 PM) If you open the VI for Call by Reference then no there isn't much if any of a performance hit at all besides of the loading and unloading itself which of course needs to be put outside the benchmarking section. For loading and calling as task through the Run method I would expect some overhead at least for the parameter retraction for the test result through the Get Control Value method. Rolf Kalbermatter

QUOTE (jhoskins @ Apr 30 2008, 07:51 AM) Well I guess we did and did not at the same time. I got the impression that the OP was not really proficeint in both LabVIEW and TS. And to have to advice someone else from this position is a tough call in any case. I do know for myself that if I would have to advice AND do the programming, my choice would be LabVIEW in most cases since my experience is there and I can be a lot more effective in it. Also we have several LabVIEW test frameworks around here which we have been programming for and with various customers for their specific needs so there is a lot of knowledge about how to do it in LabVIEW too. If someone has more experience in TS then I'm sure he will be a lot more productive for a typical test application in using that. Without some experience in either one it's sort of an open call. TS is likely to be easier to pick up for typical final test scenarious. On the other hand for more lab like test scenarious it may be beneficial to go with LabVIEW instead since you have a lot more control about how the entire test is going to be implemented. But going the LabVIEW route all the way is likely to take up significantly more time in getting something up and running as well as learning about the various topics that will look around the corner as you go about it. But independant of which way you go if you have not a good knowledge about either of these applications I would recommend anyone wanting to be productive fast to go and get a training class for the software in question. The courses may not seem cheap but they pay for themselves more than once in the time spent to get your application working in a timely manner and working good too. Rolf Kalbermatter

QUOTE (gmilne @ Apr 30 2008, 07:50 PM) Technically speaking the IMAQ Image.ctl is the control that corresponds to the wire type since it is the control type used on the IMAQ Vis to pass images around. Of course this is not what you want to see but you can always create your custom IMAQ probe just like any other probe. By doing that with an IMAQ Image Control on it you will get what you want. It is not as comfortable as just right clicking since you also have to make sure this custom probe is distributed to your other development systems but it is at least a workable workarouond for the time being, until we can find the real probe window in a Vision 8.2 installation. Edit: Ok I found the probe that you would want to use most likely as default probe. It is found in user.lib/_probes/default/ImageControlProbe.vi. Not sure why LabVIEW won't use that by default on your systems. It does use it by default on my LabVIEW 8.2.1 installation. And also has 3 "IMAQ Image Probe" entries under Custom Probes that all show the same probe too, and also a Generic Probe in there that brings up the search dialog for IMAQ Image.ctl looking for it in resource/objmgr. Rolf Kalbermatter

QUOTE (raptonx @ May 1 2008, 03:40 PM) It does sound newbish. Where did you get that LiveAcquistion_ActiveX from? Where is livewindow.vi? There are several public discussion forums for LabVIEW (both online and email ones), some with archived user submission libraries, a large samples repository at NI and some other collections of LabVIEW tidbits at various NI server locations too. Not to mention all the third party addons, both paid and free, from many different LabVIEW users and developers. All in all I would guess there are several 10000 downloadable LabVIEW libraries and code snippets in just the few most common places. And several of them to control webcams in one or the other way. In terms of requests for support I would guess that webcam access scores probably in the top ten but the willingness to share a full featured solution if it has been done is a lot smaller. From your post I would guess you got this library somewhere and it has limited support of functionality. It could be that the actual ActiveX control is limited to only support live view of the webcam itself or that while it supports more only the live view has been implemented in LabVIEW so far. If it doesn't allow extracting the actual data stream from a webcam directly or sending it to a preconfigured file you will have to look for other venues to do what you want. There are many solutions out there. Some are professional and do cost something in one or the other way, others are amateuristic and do only do one specific thing in a more or less correct way and some are just some small code snippets to show that it can be done but certainly not being meant as a drop in functionality that does everything and all one could wish. Rolf Kalbermatter

QUOTE (netta @ May 1 2008, 04:59 PM) Yes I would do that. LabVIEW 8.5.1 is definitly better in many ways and not worse than 8.5 in anything I have seen so far. I avoided 8.5 for a large part because there had been reported instabilities in various areas and until now 8.5.1 seems to work quite well for me. Rofl Kalbermatter

QUOTE (netta @ May 1 2008, 01:43 PM) Is there any known way of telling labview to ignore the images eg. icons etc... since I only need front panels available in only a small handful of VIs (all the rest are purely background processing) ? Front panels are not images. Icons are and so are glyphs such as what is used in for instance in the tree control or in the listbox as symbols. Also any bitmap you incorporate anywhere would use such an image ID. Also front panels get removed by default when building an application and that front panel is not necessary. Front panels are necessary when they are configured to be ever shown, when it's a top level VI that is eventually invoked through VI server, when an explicitedly linked property node for a control is present on the diagram and maybe one or two other more esoteric situations. What I can't say at all is which VIs that make up a GOOP object will require their front panel to be present too. Quite likely there are certainly situations where a VI needs its front panel despite that you never will want to see that front panel at all. Also while building an application those image IDs should not be constructed for the entire hierarchy if VIs somehow use them but instead they might be temporarely created during copying/compiling of VIs but then should get disposed and be reusable for other images. Not sure either if this is the real cause of your original error message. This is a DWarn, meaning it is not nice if this happens but it should not necessarely prevent LabVIEW from continuing with its task. It's just an image after all so the worst thing that can happen in normal use is that you see an empty area somewhere where you would expect an image of some sort. On the other hand it could be that at some point during the applciation build some function needs to create an image and if it does not get a valid ImageID it just bails out with said memory error, which is not really right but in a sense also not completely wrong. Anyhow I do think there is a bug somewhere that under some very rare situations tries to create way to many images for some reason. I could not really imagine how one would get into so many pictures or are you happening to use one or more tree controls with many thousend different custom symbols? Rolf Kalbermatter

QUOTE (crelf @ Apr 30 2008, 02:35 PM) You could but what would that give you other than manipulating the position and possibly the size of the floating Help Window? And if you were in user32 land already you can do that directly too, and in fact you can use the LabVIEW Help Control function to do that too (at least the position). Doing what PJM wants would require sending LabVIEW messages to LabVIEWs main event handling routine. Unfortunately I wouldn't know how to format one of those. All I have is a tiny little C code someone once whipped up for me to control the help window state when LabVIEW did not have the Control Help Window node. QUOTE (Aitor Solar @ Apr 30 2008, 09:50 AM) Umm, is that a skull in the decompose and recompose icons...? It is and you know why . It's a warning that playing with this will most likely cause your computer to start radiating deadly rays :ninja: Rolf Kalbermatter

QUOTE (Tomi Maila @ Apr 30 2008, 04:53 AM) Also if you use latch when released I never had the need so far to not use the latest value really. Other latches I have almost never used. Rolf Kalbermatter

QUOTE (MikaelH @ Apr 30 2008, 06:17 PM) No it's likely not really a normal memory error but the image.cpp error would indicate that the image manager somehow got his table of possible image IDs exhausted. Any image in LabVIEW is allocated as an entry in a table and I think the index into that table is really an uInt16. So the table can't get bigger than 65535 images. I can't say what might cause the application builder to create so many images during a build but maybe the GOOP geeks might have some ideas. Rolf Kalbermatter

QUOTE (Yen @ Apr 30 2008, 01:04 PM) Well it's a built in node so it is in every LabVIEW version but it is not shipping with standard LabVIEW in the sense that there is nowhere a menu palette where you could select it from. And NULL is the most noteworthy speciality of that conversion routine, since LabVIEW itself does not know a canonical NULL datatype (at least on diagram level). Rolf Kalbermatter

QUOTE (BrokenArrow @ Apr 30 2008, 01:52 PM) Aaaahh, but I can't enter more than three ! And besides installed does not mean I use them, and according to the personal settings page it says 1st, 2nd, 3rd LabVIEW version used. Rolf Kalbermatter

QUOTE (alfa @ Apr 30 2008, 02:53 AM) Please quit being so negative. How can you expect anyone wanting actually to work with you or have you work for them (with or without monetary compensation) if you suspect 97.3% of the human population to to be in a conspiracy against you? Ever wondered if you are not in a conspiracy against the rest of the world? You write about things that could have a deep spiritual meaning but with your attitude towards just about everyone around you you are making it mostly meaningless. One of the basic spiritual laws is that the world is answering you in the same way as you are facing the world. So try to find the part in yourself that is about love and bring it out. Rolf Kalbermatter

QUOTE (BrokenArrow @ Apr 29 2008, 08:48 PM) I do know. Just upgraded an application (which I didn't ever see before) from 4.0.2 to 8.5 about one month ago. And I have installed every LabVIEW version since 5.1 up to 8.5 and a bit more on my development computer Rolf Kalbermatter