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

QUOTE (JFM @ Apr 10 2008, 03:33 AM) Yes but what else will be going on in this loop? In the way as in the example without anything else this loop will really put a heavy load on the CPU for nothing. If there is something else going on in that loop that needs to execute as often as possible then yes I would agree that the 0 timout is a good idea, but not because it will offload the CPU in any way by not using events internally but simply because you do not want the loop iteration interval to be limited by the Deque FIFO node. Rolf Kalbermatter

QUOTE (JFM @ Apr 10 2008, 01:00 AM) But it does do so very fast then without any other means of throttling the loop iteration. I'm sure that waiting on an event of data being available would be a lot more performant than checking the contents of the queue many 100 or even 1000 times a second. But if your system hasn't to do anything else this would be a moot point. Rolf Kalbermatter

QUOTE (Giseli Ramos @ Apr 9 2008, 06:52 AM) Well NI could theoreticaly help, but for various reasons will only do so in very rare circumstances nowadays, IF and ONLY IF the VI is only corrupted. If the VI is saved without diagram resource however, they can't do anything about that anymore. Something that has been gone can't be recreated. It's like compiling a program and then throwing away your source code. With the difference that there are readily available tools to disassemble a compiled program and at least see the assembly code, while for LabVIEW disassembly is basically a no no. The only people that might still be able to do something here are those guys like from Seagate where you send in your harddrive to recover lost data from. Chances would be dim though, since the rewriting of the file has a high chance to destroy the actual data of the previous VI version on harddisk. Rolf Kalbermatter

QUOTE (Fubu @ Apr 9 2008, 11:46 PM) There is probably no way around some external code interfacing through the Call Library Node and possibly even wrapping something up in an external C wrapper DLL. Possible pointers could be libusb, an Open source C library originally from Unix to communicate with USB devices and usbhidioc, a C source code example how to access HID devices in Windows. Looking for these two search terms in Google should bring you some good pages. Although not many of them with ready made LabVIEW solutions. Rolf Kalbermatter

QUOTE (tmot @ Apr 7 2008, 10:01 AM) If it has a DirectX (DirectShow) compatible driver you could try to download the IMAQ for USB Webcam driver from the NI site. It is free but unsupported and altough it is for USB webcams, the DirectX API can also be used for video frame grabber cards. Not sure if NI might filter the available acquisition filters to USB specifically but it is at least a try. Failing that I do think going with an NI card would be definitely the fastest solution in terms of time to get this working. Rolf Kalbermatter

QUOTE (rolfk @ Apr 7 2008, 03:30 AM) There is actually one other aspect here that is important. While C and I do believe C++ will use the smallest integer that can hold the biggest enum value, there is also something called padding. This means skalar elements inside a struct will be aligned to a multiple of the element data size or the data alignment specified through a #pragma statement or passed to the C compiler as parameter, whichever is smaller. So in the case of above enum type which would result in an int8 and following structure struct { enum one_three elm; float something; } "something" will be aligned to a 32 bit boundary with all modern C compilers when using the default alignment (usually 8 bytes). So the C compiler will in fact create a struct containing an 8 bit integer, 3 padding filler bytes and then a 32 bit float. Treating the enum as int32 in that case will be only correct if the memory was first initialized to be all 0 before the (external code) filled in the values and also only on little endian machines (Intel x86). Rolf Kalbermatter

QUOTE (george seifert @ Apr 7 2008, 07:53 AM) Yes treating it as array of int32 of double the size should work quite well. You can then typecast that back into an array of your cluster type although you may have to byteswap and word swap the whole array first to correct for endianess issues. Or maybe just swap the bytes and words of the integer part. That is always something best seen in trial and error. Why it seemed to work for smaller arrays is probably because the DLL was in fact writing the first enum valu into the int32 that tells LabVIEW how many elements are in the array. As such you should have seen a swapping of the float and enum in comparison to what the VB code would indicate. With smaller arrays the overwriting did not cause to bad problems but with longer arrays it somehow set of a trigger. Rolf Kalbermatter