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

QUOTE (Aristos Queue @ Apr 29 2008, 02:30 PM) Must be standard windows message handling then, overwritten by LabVIEWs less than standard windows message queue handling. I doubt every Windwos application would bother to implement these somewhat weird key shortcuts themself. Rolf Kalbermatter

QUOTE (BrokenArrow @ Apr 29 2008, 05:15 PM) Except VISA maybe, that seems like an interesting number of things that might be responsible for at least some part of speed improvements. Of course the LabVIEW compiler got smarter too, so memory copy optimizations could have a significant effect too but that very much depends on the architecture of your application. Hearing that it used lots of globals it's not likely that it's architecture lends itself very much for LabVIEW to use its optimization strengths. But getting rid of globals might have done this trick in two ways. First saving lots of data copies just for the sake of the removed global itself and the necessary changes in architecture might have given LabVIEW a chance to actually use optimization in other places too. Of course not having run VIs in the background for no good (most likely not being implemented as smart state machines either) certainly will give LabVIEW some leeway too in utilizing the CPU for more useful things instead. I take it, that you do not compare the execution speed of your LabVIEW 5.1 application on a Pentium 133 with your new LabVIEW 8.2 application on a 2 GHz Dual core Rolf Kalbermatter

QUOTE (jhoskins @ Apr 29 2008, 05:19 PM) No argument about that. I just am not convinced that calling DLLs or external code in general is a strong point of TS in comparison to LabVIEW. If you do testing however then there is no doubt that TestStand gives you a nice framework that lets you concentrate on the actual tests and what data you want to store instead of having to bother about the test sequencer itself and how and where you want to get the test data into some database. I could be wrong however. Never used TestStand for serious work as I'm not in general writing typical test applications. Rolf Kalbermatter

QUOTE (jhoskins @ Apr 29 2008, 04:40 PM) Hmm, I only write DLLs in C (MSVC, CVI, GCC) but that on Linux, Mac and Windows. And I never had serious problems like what you describe that were not caused by my own stupidity. Also LabVIEW except in 6.0/6.01 does not have trouble to call LabVIEW DLLs. It does get a bit tricky for DLLs that are not compiled in the same LabVIEW version as the caller since you can't use native LabVIEW datatypes (handles) then. But if you intend to call that DLL with other environments than LabVIEW you do not want to export functions that use those types anyhow but use normal C datatypes instead. On the other hand I have interfaced LabVIEW to third party DLLs such as from Delphi and Borland C and even some GNU made ones and there never was a problem that couldn't be solved with a wrapper and this was normally caused by things like callbacks or complex structure parameters where trying to do it directly in LabVIEW was simply to much of troubles (although even that can be done without going to write a wrapper if one insists on it). You mention that you interface to C++. Does that mean that you can directly access C++ interfaces in Teststand. It would seem somehow unlikely to me since each C++ compiler uses its own binary object interface format so it could only relatively easily be compatible to the object layout of the compiler that was used to create TestStand. Unless you can interface directly to C++ interfaces it would not seem to be very different to what one can do in LabVIEW. And .Net oh well, you can do that in LabVIEW too. Not that I have done that much with it, as it would seem to me one more way to tie myself exclusively to Windows. Rolf Kalbermatter

QUOTE (BrokenArrow @ Apr 29 2008, 10:27 AM) It really depends! If the front panel is in memory (because it was shown at some time or because you use property nodes for front panel controls inside it) then yes the controls will be updated (but not drawn). Maybe that LabVIEW 8.x added something to this so that a front panel maintains data state even if it's front panel is not in memory but I'm to lazy to check that at the moment. Rolf Kalbermatter

QUOTE (jccorreu @ Apr 25 2008, 11:32 AM) Well it still could be just coincidential synchronicity of course but some reported near death experiences under rather well monitored circumstances would clearly indicate that brain activity is NOT inducing our personality nor our experience. Some of these people have reportedly been dead in a clinical sense, meaning no brain activity whatsoever, yet after returning they could describe both clear experiences in some other dimension as well as sounds, words, images and situations that had been going on around them while the instruments showed they were "dead". So no brain activity but still experience of dreams, sight, hearing, smell, including being able to "know" what people were thinking at that moment. From this I would conclude that brain activity is maybe a common effect while people experience something but by no means a necessary one. Rolf Kalbermatter

QUOTE (jhoskins @ Apr 28 2008, 04:28 PM) I would say that there is very little about DLLs that LabVIEW can't deal with and nothing which couldn't be solved with some wrapper DLL sometimes. That said you do want to understand some serious C coding if you are going to interface to complex DLL situations. As to debugging DLLs: Of course that is not done in a LabVIEW state machine. You do not debug DLLs in real applications but in test frameworks. In my case that are sometimes (not very often) simple C programs, but mostly simple LabVIEW programs that call a number of VIs that interface to the DLL in the necessary order and with the right parameters. Once you got that right and the DLL interfacing (and the DLL itself of course) seems to work you can go and integrate those neatly programmed VIs that you created to interface to the DLL(s) into your real applications. This way you seldom have to revisit the interface code and if you do get across something strange during application development, try to reproduce these things in your DLL test framework and fix and test it there. If done right your test framework will grow and with a very simple framework manager you can simply run every single test of it after each modification to the DLL or it's interface VIs, to make reasonably sure you did not introduce a regression. Rolf Kalbermatter

QUOTE (rejgina @ Apr 28 2008, 08:54 PM) Please read the introduction to LabVIEW first and then a bit about clusters, bundling and unbundling. Rolf Kalbermatter

QUOTE (Yen @ Apr 26 2008, 03:04 PM) It shows for me in the status bar but that didn't help. How should someone know what rickrolled is when you have never heard of that before. Funny? Not really it just reminds me of a time when I was young and you couldn't go out on a Friday or Saturday evening without hearing this Rolf Kalbermatter

QUOTE (cmay @ Apr 25 2008, 11:37 AM) But clusters without (strict) typedef are really unpretty to handle when you make changes to them. I prefer to typedef my clusters whenever possible and just do the UI discretly. The clusters are arranged to be compact and logically well ordered, whereas the UI is meant to be easy to use and intuitive. Often two things that are not easily combined. Also I have many times had that the UI has changed in very strange ways due to user requests that would have been very bad if they had to be adapted to the internal logic of clusters in the actual functions too. I did use clusters in front panels for quite some time in the past but have entirely stopped with that for all these reasons. I guess it also depends what your audience is. Mine are end users that do not care much about how I solve a particular problem inside the application but can be sometimes very particular about the UI in ways that I wouldn't even think about when programming, sometimes to the point where pedantic is just a cosy name for the requests. Having the UI as independant of the internal logic as possible has saved me many hours of work in the past when the application was completely finished and all those very specific requests suddenly started to materialize. Things like it doesn't work like Excel are only a tiny peak of what you sometimes get to hear in those final reviews. Rolf Kalbermatter