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

QUOTE (Anders Björk @ Mar 17 2008, 08:59 AM) Hmm I just get a box with a whole bunch of CDs for the quarterly shipment. Basically no paper in it. Maybe the Developer Suite subscribers were treated more environmental friendly for some time already Rolf Kalbermatter

QUOTE (sachsm @ Apr 14 2008, 09:49 PM) Windows CE or Windows Mobile as it is named nowadays really is not a realtime OS at all. It is rather designed to bring the Windows desktop experience to small and resource restricted devices than to do anything in realtime. And the LabVIEW module to create applications for PDA devices certainly doesn't make many attempts to squezze extra performance out of the whole thing. In my experience LabVIEW PDA is best used to create simple GUIs for control and/or supervision of RT applications or such elsewhere, such as on a cRIO target or similar. Rolf Kalbermatter

QUOTE (Yen @ Apr 14 2008, 02:32 PM) Yes that could be one of them. I usually keep them disabled to not accidentially discuss them on some public forum :ninja: Rolf Kalbermatter

QUOTE (reemon @ Apr 14 2008, 12:46 PM) Don't use the Basic Serial Write and Read.vi. It won't work without modifications for a modem, since it does not append carriage return/line feeds automatically to the send string or terminates on such a received character when receiving strings. Also do not remove the reading part. AT commands will almost always (with the exception of very few commands or if you specifically disable it with an AT command) send something back to indicate of the success of the command. It is exptremely helpful to verify that after you send a command the modem is really returning OK (or something command specific) to the command. The modem could be in some mode that does not allow a specific command at the moment and without indication of the command status you could debug hours if not days before you suddenly stumble across the problem. Rolf Kalbermatter

QUOTE (reemon @ Apr 14 2008, 09:55 AM) As said the INF file is handy if you want to use the modem from within Windows directly and also to gleem a possible initialisation string to use. There is not a big issue if you don't have that, as long as you have a manual that documents the AT commands the modem understands. This is very important since although most GSM modems will support some form of ETSI compliant command set, I have not really seen any modem so far that implements the ETSI standard to the letter. Rolf Kalbermatter

QUOTE (reemon @ Apr 14 2008, 05:22 AM) Well about an example to do VISA communication with serial devices you best look into the LabVIEW examples. There is am example examples\instr\smplserl.llb\Advanced Serial Write and Read.vi that should give you some sort of Hyperterminal like functionality and looking at it's diagram should give you an idea. About the INF file: Yes it would be nice to have a CD or floppy with such a file for your modem. It would be used to install the modem as a Windows recognized modem so that you could use it from Windows software. For talking with the device yourself through Hyperterminal or LabVIEW you don't really need such a file at all, other than looking into it will give you some ides about what initialisation string to use to setup the modem in a known state after connecting to it. Rolf Kalbermatter

QUOTE (tushar @ Apr 13 2008, 06:29 AM) Hmm, how did you get at that in LabVIEW 8.0? As your post indicates in this forum you seem to be aware that it is a private property and as far as I know you shouldn't be able to see that in the normal popup menu. As far as I know this is a data storage that is used for the LabVIEW Wizard like features such as what the user access control for front panel controls does (you get that as part of the DSC Toolkit). Basically Wizards are configuration tools that get installed in the right click popup of controls for specific data types. Those Wizards rovide a user configurable dialog that allows some configuration and then store that data in this property to be stored to disc with the control. The data contains both the information for what methods to invoke on specific events as well as the Wizard specific custom data to be used by these methods. An interesting feature but complentely undocumented as far as I know, both in terms of how to install the Wizard configuration dialog in the popup menu as well as how the data needs to be formatted correctly. Rolf Kalbermatter

QUOTE (wan81 @ Apr 10 2008, 03:56 AM) As you have found, ActiveX/COM interface documentation is absolutely necessary to be able to integrate such a software into LabVIEW but by no means sufficient. Without some examples that show how to use it, it is almost impossible to do something useful with it. While it would be very nice if those examples would come in LabVIEW VIs this is typically only happening in paradise. But some Visual Basic examples should be the absolute minimum anyone publishing an ActiveX interface needs to come out with in order to make that documentation not just an exercise in vain. Try to find them and if they aren't there bug the manufacturer for them. Rolf Kalbermatter

QUOTE (reemon @ Apr 13 2008, 07:01 AM) VISA is an API not an installer and therefore you do not use VISA to install a modem. Your modem should come with an INF file and better yet a real installer that will tell Windows how to control it as a COM port. Also most GSM cards will usually install as COM port somehow. Once you can see a COM port in the Widnwos device manager for your modem you can start fiddling around with it. A good start is trying to connect to it through Hyperterminal. A simple AT command should give you then an OK response. If it works that far in Hyperterminal your next step is getting to know VISA and starting to send commands to your modem through VISA. Most serial GSM modems will more or less adher to the ETSI command standard that is based on the Hayes AT command set and extended with specific commands for SMS message handling, transparent voice mode and many more things. The crux here is the "will adhere more or less" since each modem manufacturer likes to invent a few modem specific commands that will not work or at least not in the same way on other modems. Rolf Kalbermatter

QUOTE (billyt @ Apr 12 2008, 11:12 PM) Well they probably are of those kind who think anything but C programming is to high of a level :-) and assembly programming is the real thing. And they might be right in certain areas. After all you don't use a normal comfort car for off road driving, but on the other hand an old jeep with unsynchronized gear shift really sucks for normal street traffic and lets be fair how much of off road driving do most of us here do? Rolf Kalbermatter