Rolf Kalbermatter

QUOTE (Jolt @ Apr 9 2009, 02:54 PM) All these things are one of the reason to not use ActiveX or .Net for things that can be solved otherwise. The HTTP protocol on the client side is not that terribly complicated to not implement it directly in LabVIEW. LV_FPGA has posted his code. In the CVS repository on OpenG are some HTTP Vis too, that haven't made it into a released OpenG package yet. Rolf Kalbermatter

QUOTE (Steen Schmidt @ Apr 7 2009, 03:50 PM) I haven't done much with vXWorks and certainly not used any resources in such a project so I can't say with authority but I don't think the VxWorks build system actually knows something like that. The Pharlap system uses simply a PE (portable executable) image format and such DLLs can contain resources but if you can't use a VI calling the Windows APIs to retrieve the file version, the Pharlap OS probably lacks proper API support to deal with the resource part of a PE image. At least for headless systems such as the LabVIEW realtime controllers this seems like a very sensible decision as it makes not so much sense to support a fully fledged resource access API when most of those resources are mostly used for UI purpose only. Rolf Kalbermatter

QUOTE (jcarmody @ Apr 7 2009, 09:54 AM) How would you want to do that? LabVIEW is strongly typed and the only way to do what you want to do is using variants, but the internal C interface to them is not documented anywhere (though I have to admit I never inquired if it could be gotten in some semi official way anyhow such as what we got for the old scripting API that is also used in the script node interface of LabPython). But even using variants you usually have to convert the data back to some datatype in the end although you could of course go for strings if it is only about displaying them. If you only want to convert to strings I believe you should be able to do so already since the used Python API should actually be able to return string format for all its datatypes but it's a long time ago that I have played with this and it could be that there is somewhere a problem that makes this fail. Rolf Kalbermatter

QUOTE (greatwall @ Apr 6 2009, 11:04 AM) There are basically three possibilities. The first type of pointers are scalars passed by reference such as your first parameter (int* name) is. This is not a problem in LabVIEW. The second are arrays passed to the DLL such as a (char *buf). These have to get allocated by the caller in all cases and you can do that in LabVIEW also using for instance the Initialize Array function. The third are arrays passed by reference (char **buf) both allocated by the caller or the DLL. Since LabVIEW doesn't have a pointer datatype it can not really represent such a datatype itself. And if the DLL allocates such a pointer things get even more complicated since LabVIEW has no way of knowing what type of heap manager allocated them but it has a very specific expectation of how memory blocks are allocated. If you can change the DLL (even if you have the source code that is not always an option) you can adapt the functions to play with compatible LabVIEW datatypes or use the LabVIEW memory manager functions from extcode.h to create functions that accept directly LabVIEW native datatypes. You would then configure the corresponding parameter in the Call Library Node to Adapt to Type. Doing this last option requires both a very good understanding of C in general as well as about the use of those LabVIEW memory manager functions. If changing the DLL is no option you can always create an intermediate DLL that does translate between whatever the original DLL requires and what works best for the LabVIEW interface. Here too you have the choice to either use LabVIEW compatible C datatypes or use the LabVIEW memory manager fucntions to deal directly with the native LabVIEW data buffers. Rolf Kalbermatter

QUOTE (Aristos Queue @ Apr 7 2009, 12:48 AM) Very right here. Sometimes I wonder if starting up my PC might not already be some violation of some license agreement I somehow, sometime clicked away without really bothering to read it . Not that this would bother me to much as I have good hope that such a license agreement would not be enforceable in any way, but still. While I also loved to know how software worked back then I usually only went as far as getting things apart to the point where I could see how I could go around whatever protection there was. At that point the attraction somehow went away to go further but I had some friends that for sure did it for the hack itself and wouldn't be satisfied before they could distribute a tape (C64 ) with the cracked software and at least a screen hacked into the game somewhere with their alias in it. My brother and me instead took older C64 apart and rebuild them to control the light show in a disco club. You could say the first attempts at embedded development and it was cheap too, if you didn't account for the hours , which at that time wasn't a fully paid job anyhow. Rolf Kalbermatter

QUOTE (crelf @ Apr 6 2009, 05:11 PM) Ah but last time I checked the shortcut menus of build-in LabVIEW objects seemed still to be straight coded up in the LabVIEW C source code and not some hidden LabVIEW VI somewhere. So that seems like a problem to me :headbang: Rolf Kalbermatter

QUOTE (xavier30 @ Apr 6 2009, 08:36 AM) Or the libraries g++ 3.4 uses are buggy. It has happened before. Open source doesn't mean bug free! Or using g++ 3.2 only hides the problem for now and there is still a bug in your shared lib. Just because a shared lib is not crashing does really not mean to much about it not having illegal pointer releases or accesses. It could just happen to occurr in a situation that does not crash for the moment and semmingly small changes in the code or even in the LabVIEW app can trigger the crash. Rolf Kalbermatter

QUOTE (Neville D @ Apr 3 2009, 03:54 PM) At least someone cleaned them up in the meantime aligning the nodes wires and added error clusters. The old code when it was acquired by NI definitely was about how NOT to write proper LabVIEW code. It violated just about every style guideline that was ever released about how to code LabVIEW VIs. I wonder if the original C code behind it was just as messy, but doubt it as it would be almost impossible to make such a big and complex piece of SW work at all then. Rolf Kalbermatter

QUOTE (Klompmans @ Mar 31 2009, 10:02 AM) Well I have to say that in the old days I was wishing this too a lot. Before starting with LabVIEW a long time ago, I had worked with a graphical aditor called ged. This was a Unix graphical editor usable for all kinds of things but in our case we were drawing schematic designs with it. It had a pretty fixed UI: a big drawing area, a button bar on the right border with clickable commands (configurable with a configuration file as to what exact command they should do), and a command line on the lower edge where you could also type in all the commands from the button bar as well as many more. The design was stored on disk as a ASCI file and could then be used as input to various other tools such as a PCB editor or an ASIC development toolchain. I was rarely using the buttons on the button bar but almost constantly typing the abbreviated commands. Sure it required some time to get used to the commands but once you knew them there was no way someone using the mouse could even get close in speed :laugh: . When starting to work with LabVIEW I loved almost everything about it except the lack of such a command line interface. However that was in the days of LabVIEW 3 and there was no way one could get access to the LabVIEW interna like it is possible now with the scripting interface. There was supposedly a much opener C interface to the LabVIEW kernel (anyone remember tools like SurfaceVIEW or the predecessor to the Vision Toolkit developed by Graftek, or the first version of the Picture Control, who all made use of methods in that C interface not exposed in such a way anymore since a long time) but to be able to use that, one had to basically be intimate with a lot of the LabVIEW interna in a way that was impossible for someone not having worked in the LabVIEW development team. I think QuickDrop is a good addition but in my case it is about 10 years to late . I'm not sure I still feel like memorizing keyboard shortcuts for various operations that have gotten so ingrained in my cerebral system that I only have to think about them when something about them has changed between LabVIEW versions :laugh: . That is also why I hate it so much (loat it actually) that the function palettes get reshuffled with almost every new version. Rolf Kalbermatter

QUOTE (EHM @ Apr 3 2009, 02:57 AM) No problem here with that URL when I use the OpenG HTTP VIs. I'm not using a proxy but this shouldn't really be a problem. Go get those VIs (there is no HTTP OpenG package yet so you have to get them from the sourceforge CVS repository) and look at them. Rolf Kalbermatter

QUOTE (manojba @ Apr 3 2009, 02:27 AM) No. While the VI is not executing, the menu bar and toolbar will always be visible. And you really should rethink your application design. A VI that has to be started with the run button is ok if it is a lab type experimental setup to be run in the LabVIEW IDE. But once you built an application you want it to behave as such and not as VI. So create a main loop in your diagram with an event structure inside and make a start button or something on the front panel to start whatever operation you have in your VI now. Rolf Kalbermatter

QUOTE (Mark Yedinak @ Apr 3 2009, 02:43 AM) Are you sure you have really enabled "Defer Front Panel Updates". 3.2 ms for an Add Item Tree element sounds fairly long although I don't have specific numbers. Or was this 3.2 ms with an already heavily populated tree? I do think the suggestion to built up an internal data structure first that represents your tree as an array of clusters and after that populate the tree from that is probably not a bad one. It also gives you better performance check abilities to see if the file enumerating or the tree population is really munching up the big part of your processing time. The other suggestion to only update the tree as it is getting needed (when a folder item is expanded) would be my first approach anyhow. No need to go through a lengthy recursive folder enumeration when the user newer will look at 99% of those items anyhow. Rolf Kalbermatter

QUOTE (ssteven121 @ Apr 1 2009, 04:11 PM) Have you tried reinstalling (or repairing) DAQmx? Rolf Kalbermatter

QUOTE (zythum @ Apr 1 2009, 07:24 AM) No you do call RegisterWindowMessage() but then you do not call SendMessage() but you have to receive that message from the other application and that requires at least intercepting the internal LabVIEW message queue (example I pointed out earlier) but since it is a system message maybe even installing a real Winddows message hook. While the Windows Message Queue example I mentioned earlier would help you with the first, you will have to REALLY write a C code DLL to do the second. Rolf Kalbermatter

QUOTE (SandeepC @ Apr 1 2009, 04:24 AM) Lot of work and I'm sure you can never reach the short latency in this way that the native USB port would provide, at least if you have no bad hubs or such in between. Rolf Kalbermatter

QUOTE (SandeepC @ Mar 31 2009, 11:40 AM) Are you seriously considering to write an USB protocol stack in LabVIEW using the RS-422 IO lines of the 1426 card?????? I would really reconsider that again. USB is NOT RS-422 although with an RS-485 port (bidirectional) you probably could simulate it electrically. But that still leaves you with the USB protocol stack to be implemented. The TTL pins definitly wouldn't be electrically compatible to simulate even the electric aspects of USB. Why are you even considering to connect that device to this framegrabber. Wouldn't be a direct USB port on the computer where this board is plugged in be a lot easier? Rolf Kalbermatter

QUOTE (zythum @ Mar 31 2009, 03:26 PM) Yes a good start but the most easy thing of all. That example is about posting a message to another application. That is simple, even trivial. You need to wait for a message from the other applciation, that is a lot more involved. Rolf Kalbermatter

QUOTE (karthik @ Aug 17 2007, 09:06 AM) One thing I have noticed is that at some point Agilent, then still HP was marketing Vee rather agressively trying to get every LabVIEW account they could. This has changed a lot in the last 8 years. Now they try to market it together with their devices to Agilent shops (customers heavily using Agilent devices) mostly and seem to have abandoned most other venues to sell it. As such it would seem to me to have a rather limited user base. It certainly is second to none if you only have to deal with Agilent devices and like the way you have to think and program in Vee, but for most anything else it has no advantages to LabVIEW and IMO, a lot of disadvantages, but it's been a long time since I played with an evalution version of it. Rolf Kalbermatter

QUOTE (No.1 @ Mar 30 2009, 08:56 PM) Neither am I. I use my own ODBC based VI library and ODBC does not know an explicit cancel method but you simply close the statement handle (a specific query or other SQL statment execution) with an option to force it. What that does on the server side is however quite a different story since it is ODBC driver specific. It could communicate the closing of the statement to the server and cause it to abort any ongoing activity on that statement but it could also just close the handle on the client side and let the server continue with whatever it is doing, eventually discarding any response from the server it gets for this particular statement. Rolf Kalbermatter

QUOTE (Mark Yedinak @ Mar 30 2009, 04:35 PM) This would seem mostly a useless restriction to me unless for security reasons, when you want to restrict the firewall passthrough both on the outgoing and incoming side. Rolf Kalbermatter

QUOTE (No.1 @ Mar 29 2009, 10:41 PM) By not using high level VIs but taking apart your query into at least an Execute query and the actual data retrieval. If you close the statement or result set reference before you actually retrieve the data, the query should be dropped and any already generated data with it. You probably need to find a way to see if the query already produced some data before starting the retrieval as it might not be possible to cancel an already started data retrieval. You can try it out however if closing the result set reference in another part of the code does maybe abort the data retrieval too. Rolf Kalbermatter

QUOTE (hma @ Jun 8 2007, 08:02 AM) I understand now what you want, but don't feel this type of Tab Control is ergonomic in any way. I usually feel annoyed whenever I see a tab control that goes over more than one line of tabs. The variant with scrollarrows to the right to scroll through more tabs than what is possible to put on the screen is only slightly better IMO. Personally I prefer for cases like this the array index display approach with a Pull Down menu control or a List Box control being the element selector and the rest of the page presenting the currently selected array element. And that is not just because it is easier to do in LabVIEW than the multi row tab control . Rolf Kalbermatter

QUOTE (Clio75 @ Mar 27 2009, 04:37 PM) Scan from String will not have this problem. And if you know you could have numbers with a specific decimal point instead of the current system decimal point (instrument responses for instance) you just prepend the %.; to the format string. Rolf Kalbermatter

QUOTE (xavier30 @ Mar 27 2009, 11:17 AM) So you are supposedly using the Call Library Node to call those external Libraries. Ever checked (really really throughfully) that you pass all the right data types to the Shared lib, and most importantly never pass in an array or string buffer to the lib to be filled in by this library that could be to small? The fact that it works in the IDE or on Windows means really nothing in the case of such problems. The buffer you pass into the library might often border non vital data that gets corrupted too, but won't cause a fatal crash or it might be even so that it is a buffer for a filepath that is shorter in those other situations never overwriting illegal memory except in the runtime installation. Lots of things to consider here, but using the Call Library Node and testing your application to not crash on one specific installation/built is really not enough. You really ought to validate every single Call Library Node to have all the data types right and most importatnly either have no output data buffer (array or string filled in by the library) or that those buffers are under all possible circumstances preallocated large enough in the LabVIEW diagram. Rolf Kalbermatter

QUOTE (ned @ Mar 28 2009, 02:01 PM) Ben is right. No need to request the TCP Open to open a specific local port at all. Just leave the local port input empty, which tells LabVIEW to let the OS select whatever port it can. For a client (No TCP Listen used) only the remote port is normally important, except with some strange protocols sometimes. Rolf Kalbermatter