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

QUOTE (Tomi Maila @ Mar 25 2008, 04:03 AM) Bad maybe but not entirely unexpected. Dragging is an UI operation and therefore for sure executed in the UI thread, just as all the other events that are in fact UI events. The event structure itself is not executing in the UI thread but the routine fetching the UI events from the OS and distributing them to the various event queues for the event structures sure enough does. Rolf Kalbermatter

QUOTE (Mads @ Apr 25 2008, 03:03 AM) Which is basically what I meant when I said "that I have long ago stopped to use them on the visible UIs". They are a great programming aid, but not great on an UI at all. Rolf Kalbermatter QUOTE (cmay @ Apr 25 2008, 03:06 AM) Why would this have to be the case? Instead of tabbing to the cluster container, LabVIEW could automatically tab to the first element inside the cluster. The overall tabbing order could still be preserved as follows: 0. Numeric Control 1. String Control 2. Cluster Control Container (ignored) 2a. Path Control 2b. Numeric Control 3. Boolean Control Where "a" and "b" are the 0th and 1st elements in the cluster. How do they restrict the UI design? I think in general they help clean things up rather than having individual controls on the block diagram for potentially similar and repeated sets of controls. Because the element order in a cluster is not always the desired tabbing order on a front panel at all anyhow. The cluster order is and should be dictated by the logical data it represents and is more often than not determined by the functionality (VIs) that operate on it. But this is more often than not, not the same that I would want a user to be presented with. For one there can be controls inside the cluster that a user should not be bothered with. For another one I prefer to have all my subVI front panels use classic controls and my UIs to use system controls. That precludes typedefs anyhow beside of the fact that typedefs do have some particular behaviour that is not making them very great to represent both the programming interface of a cluster as well as the UI interface. Using individual controls on the UI is a bit more work initially but gives you every freedom to keep the UI completely independant of the underlying data structures, giving you the freedom to change them without having to revisit every UI to readjust just about every control on them to the new layout. Rolf Kalbermatter

QUOTE (Aristos Queue @ Apr 25 2008, 01:13 AM) I take it with structure nodes you mean (Stacked) Sequence Structure Nodes and maybe Case Structures, but not loops? I thought of them as Structure Nodes too until now but this is probably not the classification the LabVIEW team is using. And in that respect the notion that a sequence structure does not cause any significant runtime delay ever certainly has to be reconsidered too. If there are asynchronous threads like this (or any other VI server proxy threads) waiting they will be serviced and delay the execution of the sequenced code. Until now I was rather assuming that this would only happen at specific asynchronous nodes such as Wait (until multiple ms) etc. Rolf Kalbermatter

QUOTE (Christina Rogers @ Mar 16 2008, 08:50 PM) Now that is a fancy workaround! And I was always thinking that sequence structures had no other runtime influence than enforcing execution order. In this case they obviously do more since they logically wouldn't do more than what the error cluster is already doing. Rolf Kalbermatter

QUOTE (cmay @ Apr 24 2008, 05:37 PM) Well I'm sure there are people that would think so. But the real issue is, that a seemingly simple request like this can have far spread effects that can and I'm 100% sure have been discussed at length in the LabVIEW development team at some point. For starters: If you give up the current behaviour, which btw has been there since LabVIEW has clusters and allows keyboard navigation, you will likely not always just want to tab into the cluster and then go through all controls inside that cluster before going to the next outside control. That would mean a completely separate tabbing configuration independant of the cluster element order. I'm sure there are quite a few other not so trivial questions and problems in that respect. And in my experience clusters are not really great UI controls anyhow. They restrict the design of an UI to much in several ways so that I have long ago stopped to use them on the visible UIs. Rolf Kalbermatter

QUOTE (Tomi Maila @ Apr 23 2008, 03:50 AM) That was my first reaction when reading the OP. Does it handle Little Endian and Big Endian TIFF files alike given that it was tested on a Mac only :-) Rolf Kalbermatter

QUOTE (cmay @ Apr 23 2008, 08:21 PM) With the event structure and key events you probably will be able to do your own customized tabbing. But I doubt this is worth the trouble. Avoiding clusters on the UI is the most simple solution by far. Rolf Kalbermatter

QUOTE (orko @ Apr 18 2008, 05:54 PM) I can't say how this is implemented for real but if I had to do it I would use some sort of caching algorithme in the Call Library itself. This would mean that I would maintain the last used path (initialized to NULL on load) and compare the new path with this path. If they match just call the function and otherwise unload the old library (Windows keeps a refcount) and load the new DLL and link to the function. So there will be some overhead to compare the paths but that should be almost neglible. Loading and unloading a DLL costs definitly more performance although typically it is probably already loaded by other Call Library Nodes so that this overhead is also not so big. Rolf Kalbermatter

QUOTE (kawait @ Apr 18 2008, 09:54 PM) Yes if you go to www.ni.com and do a search for +user +event +dll you will find eventually examples for that. As a shortcut you can also search specifically for PostLVUserEvent, which is the exported LabVIEW callback to post a user event to LabVIEW. Rolf Kalbermatter

QUOTE (tcplomp @ Apr 19 2008, 01:22 AM) If performance is your concern you should go with uninitialized shift registers for sure. It is true that the Value property is magnitudes slower than the local variable but the same applies to locals in comparison to shift registers, certainly in this case since they will be copied twice for the NotaRefnum case and image datatype typically contains arrays of some size. Rolf Kalbermatter

QUOTE (tcplomp @ Apr 18 2008, 01:36 PM) I think you misunderstood. And what you want to do is the classical use case of LabVIEW 2 style globals (Uninitialized shift register in a while loop with case structure inside). No obscure reliance on indicators being cleared and maybe not based on full moon, programmer mood and NI stock price, but clear and predictable LabVIEW dataflow (With the exception of some obscure LabVIEW compiler optimization bugs in the past in more complicated situations in some very short lived and unfortunate maintenance releases). Rolf Kalbermatter

QUOTE (kawait @ Apr 18 2008, 02:56 PM) It's not impossible but in fact to much trouble to bother with or even just explain it. All I will say here is that you would have to create a LabVIEW DLL with an exported function that matches your callback prototype and then using the Call Library Node calling LoadLibrary()/GetProcAdress() and possibly some more help functions. If you are a proficient C programmer you can come up with the exact solution but writing a wrapper DLL that translates between a callback and a LabVIEW event such as an occurrence or a user event is definitely not more complicated and a lot easier to manage and maintain. This is even true if you are not such a proficient C programmer because the LabVIEW DLL approach will still be at least as complicated to get right than writing a wrapper DLL in C and the difficulty to manage and maintain the separate LabVIEW DLL solution in LabVIEW applications will be also bigger if you do not understand DLLs and their interaction fairly good and especially the way LabVIEW runs LabVIEW DLLs in the development system versus in a separate runtime system. Rolf Kalbermatter

QUOTE (rpscott02 @ Apr 17 2008, 08:44 AM) Unless you have some basic C programming knowledge I would believe that trying to interface the DLL through the Call Library Node is actually more difficult (and definitly a lot more likely to crash your LabVIEW system regularly during development) than trying to talk directly to the device through the TCP/IP nodes. Of course that means you do need the protocol specification for said device. Without that documentation it is a very cumbersom process to get such a protocol to work and to work right. Rolf Kalbermatter

QUOTE (reemon @ Apr 16 2008, 04:57 AM) Sorry my time is limited. There are all kinds of nitty gritty things that could be a problem and checking that out could take a really long time. Part of software development is learning and debugging and that will be your task here Good luck! Alternatively you can go and look for some more or less ready made SMS Toolkits such as the http://www.citengineering.com/pagesEN/products/sms.aspx Rolf Kalbermatter

QUOTE (Tomi Maila @ Apr 15 2008, 03:15 AM) I wouldn't know but have a feeling it is not on the list of things to do at NI. And I can understand them. Adding a full featured LabVIEW embedded target to the LabVIEW development system is no trivial task. And that is without GUI support. Translating the LabVIEW GUI into plattform specific widgets is not something we could even do AFAIK as it requires direct intervention into the LabVIEW G to C converter and one of the reasons why LabVIEW PDA has a rather buggy reputation. It's really a taunting task to translate the LabVIEW widgets reasonably into the widgets an embedded platform would support and in some cases just impossible. Developing support into the LabVIEW code base for a new runtime environment would help this problem since this runtime engine can implement their own widgets in the way that suits LabVIEW best but this is a very major undertaking especially since such a runtime is OS, Windows manager and CPU dependant and a few more things all at the same time. Rolf Kalbermatter

QUOTE (reemon @ Apr 15 2008, 06:20 AM) These VIs use a low-level interface that is not available in LabVIEW since about version 5.1 anymore. By copying files (serpdrv) from an older LabVIEW installation you can make it work in newer LabVIEW versions but NI has repeatedly stated that they would like and are going to remove support for that interface sooner or later. Go with VISA if you want to build something for the future. Rolf Kalbermatter

QUOTE (Jimbo29 @ Apr 14 2008, 03:13 PM) DirectNet devices have several possibilities to be addressed. Two of them are: either by the IP adress of the PLC or by it's PLC address. Both are assigned by the software that comes with those devices. The IP address is obvious, the PLC address is typically a number between 1 and 255. Communication happens over the proprietary (although specifications can be requested) Ethernet protocol from Host Engineering Inc. using UDP. I did develop a VI library implementing that protocol natively in LabVIEW based on the UDP primitives and it is downloadable from the website of Host Engineering at http://www.hosteng.com. Some time ago I did improve the version posted at the hosteng website a bit and sent them an update for it but it hasn't made it on their website yet. It fixes a bug in the protocol implementation that did not make itself appear when using the built in TBase-10 Ethernet interface but would fail when the connection was done through an ECOM100 plugin device. I've attached that version here, which is LabVIEW 7.0 or higher. Download File:post-349-1208242588.zip Rolf Kalbermatter