Rolf Kalbermatter

QUOTE (Michael Ashe @ Sep 29 2004, 01:27 PM) When doing some debugging of my own DLL's I ran across some references hanging around in memory and looking further into this I believe that are the controls like ImageControl in <LabVIEW>\resource\PlugInControls when you have IMAQ Vision installed. Basically it seems the IMAQ control itself implemented in an external component as DLL. I do believe however that this DLL makes quite a few very specific callbacks into LabVIEW exported functions so without access to the LabVIEw source code to add specific support functions for a new type of Plugin control it would be very difficult to create a really useful control in that way. Also this looks like a mixture of VISA resource object scripting (the ImagControlRC) file and a DLL method (visible from ImageControl) that loads a C++ like object virtual table into LabVIEW. Without the actual header file for that virtual table definition AND lots and lots of documentation, there is simply no way to create such plugins. Also it is clearly a mostly C based implementation so probably not what most people here would even consider to be creating. Rolf Kalbermatter

QUOTE (rharmon@sandia.gov @ Jul 1 2008, 07:05 PM) This is a standard LabVIEW VI and I don't think there is anything wrong with it itself. It's probably more in what is passed to it in terms of parameters. This VI reads the registry from a place that is defined by an earlier VI in the chain. It's C:/.... input is only a default input to be used if the inidcated key value could not be found in the registry. Obviously it can be found and for whatever reasons is set to E:/... Who did initilize that key, when and where with that value we can't tell you. But I would assume there should be a menu entry, configuration tool or something for this application that lets you configure that value. Rolf Kalbermatter

QUOTE (Thang Nguyen @ Jul 1 2008, 05:40 PM) I'm afraid you missed the point that this is a function declaration and the parameter in question is a function pointer. And the OP should be advised that this is not possible in LabVIEW (well it is sort of if you create a LabVIEW DLL that exports a function with the right protoype, then LoadLibrary and GetProcAdress that function and pass the resulting pointer as an uInt32 to the Call Library Node that calls this function). Sort of because there are many caveats to this approach not the least is the difficulty about maintaining the whole thing. Another one is that it will play very badly once the DLL is created and you upgrade to a new LabVIEW version since the LabVIEW DLL VI can only run in the same LabVIEW process if the caller is exactly the same version as the LabVIEW version used to create the DLL. So while it is possible the solution is a nightmare to maintain in the long run. Instead the OP will have to create a wrapper DLL in C that translates between this callback function and another LabVIEW callback mechanisme such as occurrences or user events. Good luck. Rolf Kalbermatter

QUOTE (Daklu @ Jun 26 2008, 11:39 PM) He may be competent but whenever I see a Selector function used on Boolean wires I have a feeling of: Öhhh no, one more person that has missed the Boolean Algebra classes or doesn't bother to think about creating a logic state table for a boolean problem. It is so much easier to think in terms of OR and AND for boolean problems that I simply can't understand how someone could think about using the selector instead for that. Rolf Kalbermatter

QUOTE (Yen @ Jun 23 2008, 12:06 PM) Actually Windows does have pipes and they are quite like Unix pipes. The problem is that they are not really Posix compliant and the semantics are therefore slightly different. The OpenG library I created sort of works but has certain issues on startup such that the first read can sometimes timeout and similar things. The situation where this happens seems to depend on the machine used, OS version involved and quite likely also other things out of control of the programmer such as moon phase, time of day and such things I guess it could be made to work 100% reliable but I do not have the time nor currently any incentive to spend the necessary time into this also because for the situations I do use it is seems to always work as I need it to work. Rolf Kalbermatter

QUOTE (Yren @ Jun 20 2008, 02:22 AM) Its most likely just wrapping some .Net functionality built into Vista. Don't know more about it though. Rolf Kalbermatter

QUOTE (ned @ Jun 12 2008, 08:27 AM) From the function names and the model name I would think they really use ModBUS TCP as underlaying protocol. Sorry no experience with those modules myself. The last Adam hardware I used were I believe Adam 3000 modules and that might be about 10 years ago ;-) Rolf Kalbermatter

QUOTE (PhattieM @ Jun 25 2008, 04:03 PM) It's VC++ but which version? And also do you generate an ActiveX library or a function library instead. The first needs to be accessed from LabVIEW through the ActiveX nodes after the DLL has been registered on the computer on which it is to be used and you also need to make sure to create a type library for the DLL and include it in the registration. If it is a functional library then there are a few things you need to take care of. First you cannot import C++ objects through the Call Library Node. This would be difficult to create but most important impossible to support since there is no binary standard how C++ objects are exported from a library. Each C compiler does it in a different way. Instead you need to export every single method of the objects you want to access and write accessor methods for public data you want to access and export them too. Then you should make sure that your C compiler exports thos methods as standard C symbols to avoid name mangling c.q "decoration". To tell a C compiler to export functions as Standard C symbols you either prepend the function declaration or implementation with extern "C" or surround all the exported function declarations between the extern "C" { your function1() your function2() etc. } Last but not least you need to make sure those functions really get exported from the DLL. This can be done by either creating a .def file that lists all symbols that you want to export or by adding the __declspec(dllexport) statement in front of each function declaration that you want to be exported. Other C compilers while nowadays often supporting the Visual C syntax use different declarators to mark symbols as being exported from a shared library such as attribute(export) that is for GCC and I believe Borland C used that too. Rolf Kalbermatter

QUOTE (Zoyo @ Jun 23 2008, 05:29 PM) In addition to what Yen said you will not use the IRCOMM->USB cable at all. That USB interface is a real USB device interface that needs a USB host controller to interface to and that probably gets installed in your PC as a virtuel COM port. The software that makes this USB interface look like a serial port to your PC program is a driver on your PC. There is no way to directly connect that USB cable to an RS-232 port. That said your IRCOMM port is in fact most probably a serial port but as its name would indicate most probably an infrared one. So you would need to find an IRCOMM to RS-232 adapter for your device. Then you might need to figure out the pin 2 and 3 configuration as is common for serial comm and after that the real fun starts by implementing the Moeller serial communication protocol, which according to Yen there is little documentation for. Since the PDA is not x86 based an existing DLL to communicate with the PLC will not help as you can't run it on the PDA. So implementing the protocol on your own using the serial port functions on the PDA is the only solution. http://pinouts.ru/PDA/acer_n30_pinout.shtml' rel='nofollow' target="_blank">Here is the pinout of the connector but I couldn't quickly find a manufacturer of a cable that provides the RS-232 part of this proprietary connector on an DSUB-9 connector. Rolf Kalbermatter

QUOTE (baman @ Jun 24 2008, 10:46 AM) What overhead that you need to change are you talking about? LabVIEW has UDP nodes and should be able to implement just about any UDP based protocol. However implementing an RTP protocol is no easy task at all, be it in LabVIEW or C(++) so if you have already some C(++) code to do that protocol, it would be definitly a lot easier to simply wrap that code into a functional DLL (or God beware, maybe an ActiveX component) and import this into LabVIEW through the Call Library Node (or the ActiveX interface). Rolf Kalbermatter

QUOTE (marp84 @ Jun 23 2008, 12:38 PM) This forum does not work like this! We are all doing this in our own spare time and are not paid to support anyone here. So support is given based on the interest in a particular topic, experience with it and also about the general impression a post makes. Posts that ask open ended question like "I want to know how XYZ works" or "Send me an example to do XYZ" are almost for 100% sure to not receive substantial responses. What would work is describing what you want to do, AND ALSO VERY IMPORTANT what you have already done to achieve what you want to do. Show us that you have done some effort to get working what you want. Read manuals, documentation, examples etc. etc. Taking courses to get up to speed on using LabVIEW might help too. Then come back with specific and targeted questions. Rolf Kalbermatter

QUOTE (crelf @ Jun 21 2008, 07:14 AM) Ahh well! Some people are sometimes so hung up about something they can't see that it's just a good or sometimes not so good analogy. Guess he wasn't into software at all, so that may explain it a bit. I did know programming as it was part of my study and I wasn't to bad in it either. Just never really liked it very much until I encountered LabVIEW. Rolf Kalbermatter

QUOTE (Aristos Queue @ Jun 10 2008, 02:26 PM) I have an electrical engineering background and when I first encountered LabVIEW the similarity of it's diagrams with an electrical schemata was what made it very easy for me to grasp the idea and even like it very much. The rest was just getting used to specific LabVIEW ideas such as how loops, cases and such were done and here traditional programming theory from my Pascal days which used to be thought in rather formalistic ways back in those days helped of course. Thinking of wires as variables only occurred to me later when I tried to come up with explanations of how LabVIEW works but it never struck me as something elegant and I never really tried to push that idea much further. Rolf Kalbermatter

QUOTE (Antoine @ Jun 19 2008, 05:56 AM) I think your DAQ board is a bit at the low end of the NI spectrum. The higher end DAQ boards support analog triggering including pretriggering and with a long enough post trigger period you will get the entire three chirps in one acquisition. You could even route the internal trigger signal from the analog trigger to some output signal through RTSI and have that signal available external too in that way if you needed. Rolf Kalbermatter

QUOTE (Jim Kring @ Jun 19 2008, 12:55 PM) Well, if you are talking about IT departemetns of big multi billion dollar companies that might happen. But in a smaller company of 20 or so developers if the IT departement gets an annoyence they get a problem very fast I've been bitten by IT departements at customer sites being more difficult then they should have been IMHO, but if our own would be to difficult they would have a problem. Rolf Kalbermatter

QUOTE (Anders Björk @ Jun 18 2008, 09:11 AM) VB DLLs are normally ActiveX DLLs. They do not export normal functions (excpet 4 for instantiating and controllling the ActiveX server) but ActiveX objects and consequently can not be imported by the shared library wizard. Casting references might work in older LabVIEW versions, not sure about the most recent ones since LabVIEW got a lot stricter in allowing to cast object refnums into other refnums. Basically you chose a class that is the least common denominiator of all the classes that are "polymorphic" and cast each resulting refnum into that refnum class before you leave the case structure. You need to make sure that you do not use a class that allows to select properties or methods that certain classes do not implement as that would certainly cause nasty side effects if you ever execute code to access such a class property or method on a refnum that was casted from a class not implementing these. All in all not a very good idea in LabVIEW really and if casting doesn't work (anymore) you will have to change your VB object hierarchy. Personally I would think this kind of technique be a poor mans implementation of inheritence. Rolf Kalbermatter

QUOTE (jebus @ Jun 18 2008, 11:54 PM) And now with everybody knowing that this server is an open proxy it will either be changed to require login soon or it will end up on every single blacklist on this planet, resulting in you not being able to send your LabVIEW mail to many recipients, since they will often use those blacklists to filter out incoming mail for spam. I know our servers are configured to filter out mail originating from IP adresses on those blacklists. Much easier and better would have been to point your local email server to proxy for you to your ISP. Your email server should certainly be able to use proper authentification to contact your ISP SMTP server so that you have a hopefully firewalled to the internet, open SMTP server on your local network that will allow your LabVIEW program to contact it without authentification and will take care of the authentification towards the ISP instead. Rolf Kalbermatter

QUOTE (menghuihantang @ Jun 17 2008, 03:55 PM) Jason's solution is the best of course. Another more quick and dirty solution is to use the timeout input to the Listen VI. Set it to a value that is not to slow for user interaction (250ms is usually quite small enough). Of course the listen node then wil return if there has a connection arrived AND also if the timeout has expired and in the second case accordingly return a timeout error which you have to filter and ignore and go back to listening again. But as mentioned, Jason's solution is the more robust one and definitly has my preference by far. Rolf Kalbermatter

QUOTE (ned @ Jun 12 2008, 12:57 PM) Your last suggestion is the only real solution. ActiveX has in theory the possibility for a library to be invoked in various modes. One is out of process invokation in which case the ActiveX object is instantiated in its own server process and communicates through RPC and a proxy library with the client. However almost no ActiveX component supports this mode and they are almost all in-process servers. This means they run inside the process that is instantiating them and therefore can affect and also take down that host process. I'm not even sure if LabVIEW does support out of process instantiation of ActiveX components. If it does it won't be a well tested scenario since there are so few ActiveX components that would even support that. Rolf Kalbermatter

QUOTE (PhattieM @ Jun 12 2008, 11:02 AM) This should be fairly simple. For every function in the object library that you want to be available in LabVIEW through a Call Library Node you would have to write a small wrapper. Something like this: Original function as exported from the lib: int MyFunction(int param1, int param2); Your new function: __declspec(dllexport) int LV_Myfunction(int param1, int param2) { return MyFunction(param1, param2); } Then compile it into a DLL, linking this with your object library. Possibly you could maybe suffice with a modified header file in a DLL project without any other source files where you add the __declspec(dllexport) in front of each function and simply link in the object library but I never tried that. If you want to persuade the Python solution you could look at LabPython. It is on sourceforge. Rolf Kalbermatter

QUOTE (one734 @ Jun 12 2008, 04:39 AM) There is enough discussion about this. All in all this is a very clear case where trying to do everything in LabVIEW is a masochistic exercise at best. Go and write a wrapper DLL that wraps the HALCON DLL API and provides a more LabVIEW freindly interface. If you want to pass in LabVIEW native data like string or array handles you can use the LabVIEW memory manager functions as described in the External Code Reference Manual to prepare, resize, allocate, deallocate, etc. the memory blocks necessary. And by the way some good C programming basis is not only beneficial but in fact an absolute requirement to get a result that would be usuable in a real application. That is even more true so if you would want to try to avoid the wrapper DLL since you will have to deal with things in LabVIEW that are normally taken care of by the C compiler. Rolf Kalbermatter

QUOTE (menghuihantang @ Jun 11 2008, 12:36 PM) Either I'm misunderstanding you or you are misunderstanding the event handling here. The data from the Event trigger is actually passed into the VI in "Event Data". If this parameter is by reference and the event is meant to pass some data back to the trigger function I would suppose your callback VI needing to supply this data back in "Event Data Out". There is no way you will ever see data from the event trigger source in "Event Data Out" since this is an indicator and meant to pass data back to the caller. Could it be that you did not understand that the Callback VI is invoked by the external event trigger but rather think it to be the event trigger itself? (Which would not make any sense by the way). Rolf Kalbermatter

QUOTE (PJM_labview @ Jun 13 2008, 02:22 PM) First LabVIEW does not even get informed about user events that happen outside of it's own windows. There are some system events like shutdown, power management and such that get passed to all applcations but most other events like keyboard, mouse, etc. are only passed to the window that has currently the focus. That is an OS limitation and in fact a good one since otherwise user event handling would get SOOOOOOOOOO slow (and a misbehaving application could block the entire system from working properly). That said one can register hooks in the form of C callback functions into the OS for particular types of events. They can be usually global but not always, or application specific. Windows is very clear about installing global event hooks: DON'T DO IT for released code and that would include LabVIEW. It's a sure way of degrading system performance and once every application would start doing it Windows would be sluggish to the point of uselessness (Some would argue that it is that already without global hooks). So if you want such hooks you probably will have to bite the bullet and write some external code in C (and make sure to not include such code in production quality software). Also it still wouldn't help for Drag & Drop. A target is only informed about a Drag & Drop operation at the moment of entering its window in a D&D transaction. This event can be used to query the available data formats and change the cursor to indicate acceptance or refusal of the D&D application. However this interface is rather complex to use and that is probably the reason why external D&D support hasn't yet been integrated into LabVIEW D&D. I'm sure there are myriads of difficulties and complexies that make offering this interface in LabVIEW very hard to make user friendly (I mean here LabVIEW programmer friendly). To make things worse, D&D is implemented using COM and not routed through the Windows message queue. Rolf Kalbermatter

QUOTE (marp84 @ Jun 6 2008, 04:16 PM) Sorry! I'm not going to open Windows bitmap files (.BMP). Saving them as JPG would at least shorten the download time considerably and wouldn't be a lot more work on your side. Rolf Kalbermatter

QUOTE (Andre Tomaz @ Jun 6 2008, 11:15 AM) It's going directly to the ODBC API. More precisely it is for the most part relying on ODBC 2.5 features only since I started that work back in 1996 and improved on it since. QUOTE I am having a lot of trouble with ADO. I think there is a memory leak in the MS ADODB component... -I have tried many things, but all solutions using ADO seem to show the same problem. Have you ever experienced anything like this? Do you plan to put your ODBC library avaliable for other users? No I never really used ADO based libraries, not the NI SQL Toolkit, nor the LabSQL Toolkit, nor the IB Berger ADO Toolkit or the T&M Database Toolkit. There seem to be some problems with ActiveX references not always being closed in some of those toolkits. But I have not really used them so I can't give more details. My driver being for a large part a DLL/shared library also has the potential of memory leaks although I believe I got it to the point where memory leaks should not happen anymore. About putting it up for others to use, I've thought several times about it but decided for a number of reasons against it. To name a few reasons: - It works for me but its documentation sucks and its features have by far not all been tested and also not with many ODBC drivers and it's likely to fail with some ODBC drivers since ODBC is more like a RECOMMENDED standard than a real standard. - Documenting and maintaining it would cost a lot of time but I have not figured out a workable way to cover for the cost of that. Selling Toolkits does not work, selling support for it is also more or less unworkable. - Its DLL/shared library is rather advanced and I do not want to open source it. Given these reasons it simply is a lot more cost effective to not spend more time for that than is necessary for my own use. That cost can be charged to specific projects, public use as Toolkit basically not. Rolf Kalbermatter