Rolf Kalbermatter

QUOTE (Scott Carlson @ Aug 1 2008, 05:30 PM) Well I didn't take it bad in any way! I actually welcome your comments to this. The two big reasons why I haven't done much with LabPython anymore is that I don't really use it for quite some time and there is little feedback other than sometimes a single statement like it doesn't work please help and when asked back what doesn't work and to please provide some simple example that can be used to reproduce it there is usually little reaction. That and of course the fact that there is lots and lots of other work to do and some of that is either paid or for one or the other reason closer to my heart than LabPython. Rolf Kalbermatter

QUOTE (Scott Carlson @ Aug 1 2008, 12:55 PM) The guy responsible for LabPython is in fact yours truely I think you are up to something when feeling that not deallocating the canvas object after execution is the culprit. And I'm not sure that assigning NULL to an object variable will actually properly clear that object although I must add that my knowledge about Python itself is limited. As to automatically cleaning up after a script: No there is no specific garbage collection done when de script finishes execution. I'm not even sure how to do that completely safe with Python hooks as it would be hard to track down all resources that a script might have allocated itself and there are certainly cases possible where this is not even desired. I do cleanup the Python state when the script node is disposed, respectively when using the VI interface to LabPython contrary to the script node, when the Python session is closed. This should in my opinion cleanup all Python related resources that might have been allocated during that session. If you want to reuse a Python resource between script executions you should probably pass this resource as a uInt32 out of the script and feed it back in on consequent execution. On the other hand all script variables are stored inside the Python state by name so as long as the state is not modified in that respect the object may be still allocated and valid on a consequent execution. While it may seem desirable to deallocate all resources at the end of each script execution automatically it was not my intention to actually emulate a Python command shell one by one. So state information will persist between script executions as long as the scribt is not unloaded which as it is implemented now will only happen when the VI containing the script node will leave memory or in the VI interface to LabPython when the session is closed. Rolf Kalbermatter

QUOTE (iowa @ Jul 21 2008, 06:06 PM) I'm doubt you find it. Automating user interface testing on a Windows API level is absolutely not trivial (hence contradicts your requirement of simple LabVIEW examples) and is the reason there exist software packages like AutoIt. If you really hope to build an extensive UI testing framework for non-LabVIEW applications don't go and try to use LabVIEW for it. Of course it can be done as there is virtually nothing that couldn't be done in LabVIEW if it can be done in a program at all, but it is going to be a major pain in the ######. Feel free to research the Windows API on MSDN and proof me wrong but asking for simple examples here is not likely to give you anything useful. Rolf Kalbermatter

QUOTE (Gerod @ Aug 1 2008, 02:43 AM) To your question: not really!But you have quite a few things in that script that access external components to Python. I'm not going to setup an SQL server and a PDF formating solution to test something like that. Can you reproduce that with a simple Python script too?The problem could be in the type conversion inside LabPython between LabVIEW and Python but it could be just as much be something in one of the other components involved or a bad interference between one of these components and the fact that Python runs embedded inside LabVIEW. It could be even that Python or one of these components does not like something LabVIEW does for its executable environment and the way LabPython is done it will run and execute Python and everything in there inside the LabVIEW process. In that case it could be a possibility that it is even LabVIEW version dependant. Rolf Kalbermatter

QUOTE (solarisin @ Jul 30 2008, 02:44 PM) You need to give a bit more information here. Where do you see an array here? VARIANT* is a pointer to an OLE VARIANT which could contain an array in about 50 different type and format variants but it could be also a timstamp, numeric of any type either by value or reference, a NULL or quite a few other datatypes. The first word in that VARIANT record contains the code which tells you what the VARIANT really represents in terms of data. And the actual data, certainly in case of arrays or strings is not directly embedded in the variant structure since that structure is fixed size and can only hold directly information for I think 8 databytes. The rest is by reference meaning it is a pointer and after you receive such a VARIANT from somewhere you also need to make sure to release the resources that might be contained inside such a variant such as by using the according VariantClear() API from OLE. As to extracting data from a variant while you could do that by hand what is usually done is to verify that the vt_type is actually what you expect and then use the according OLE APIs (such as SafeArray....() ) to extract that information from the variant. Rolf Kalbermatter

QUOTE (jlokanis @ Jul 25 2008, 12:36 AM) It is slow since you typically have to execute several methods/properties to update it. After each method/property node it is redrawn ... unless you use the defer panel update method. Switching that on before a tree control update sequence and then off afterwards makes updating a tree control a lot faster. Rolf Kalbermatter

QUOTE (JCFC @ Jul 17 2008, 08:14 PM) You can't with the Call Library Node directly! This is C++ with function pointer virtual tables and simply can't be implemented with the Call Library Node unless you want to write lots and lots of nitty gritty code on the LabVIEW diagram which takes care of things a C++ compiler does for you without you having to worry about anything. This is something were a wrapper DLL would be required which wraps the access to the virtual table function pointer into a normal C function and exports that one. However in this particular case there are several exported Shell32 APIs that deal with PIDLs and are in fact already this kind of wrapper you want here. So researching MSDN to see what kind of functionality shell32 contains will certainly give you an exported API that does more or less exactly what you want to do here. Rolf Kalbermatter

QUOTE (sisson @ Jul 15 2008, 01:46 PM) The SQL Toolkit uses ADO, the Windows ActiveX implementation. It's error codes are therefore also really Windows error codes. Windows error codes for COM, the technology where ADO/ActiveX is build on, are all unsigned and normally hex formatted. Your error results in a code 0x80030002 and looking in the Widnnws SDK for this error code shows STG_E_FILENOTFOUND from the subcategory FACILITY_STORAGE. So your guess that it has something to do with the UDL file does seem not so bad although it is not conclusive. It could be any other file involved in ADO handling of the database provider. Rolf Kalbermatter

QUOTE (MSpidey @ Jul 1 2008, 11:20 AM) Are you sure it is the MSP430 itself. I would expect problems with C runtime libraries that use string formatting to format data to be sent over a serial line but the low level interface hopefully doesn't care about such details. Rolf Kalbermatter

QUOTE (DrTrey @ Jun 30 2008, 04:41 PM) You give indeed to little information about the type of device and such. If it is some DAQ device or similar however the standard mode of operation is to write a device driver and the according user space DLL wrapper. That can be easily imported into LabVIEW through the call Library Node in a way that is completely independant of the LabVIEW version. Other means would be to use libusb to control your device. Interfacing LabVIEW to libusb through the Call Library Node is about the same in terms of version dependance but the libusb API is not really meant to be interfaced by high level applications like LabVIEW or VB and you will run in some issues that are usually most easily solved by writing a wrapper DLL that translates between the low level API and the LabVIEW Call library Node. Last but not least there is USB Raw device support in NI-VISA. Not sure though from which version of LabVIEW this VISA feature is properly supported. While the feature is completely implemented in VISA, LabVIEW needs to support some extra API access modes to use this feature. A quick look in LabVIEW 6.0 shows that the necessary Nodes to use USB through VISA are not present. LabVIEW 6.1 is the first to support this interface but you will need a recent version of VISA installed on your computer. The first VISA versions had lot's of difficulties supporting USB device RAW access. Princiapially option 1 will require you to really write C code. The other two options won't but can't be really considered a lot easier. You will simply implement the bit level protocol of your USB device in LabVIEW itself. Option two will still require some serious C knowledge to be able to properly interface to libusb through the Call Library Node. From that perspective using VISA to control your USB device would be probably the simplest solution but don't expect it to be trivial. One disadvantage of the two last options will be that you can't really leverage off that solution for non-LabVIEW users such as Visual Basic, Visual C, etc. Rolf Kalbermatter

QUOTE (Tomi Maila @ Nov 9 2007, 07:58 PM) User defined tags and user defined refnums are in fact quite like normal LabVIEW refnums. The Tag variant looks like a VISA resource and can have a text label that identifies the instance of the object. The refnum type looks similar to a file refnum. Those refnum types allow creating an object/method/event hierarchy using *.rc files in <LabVIEW>/resources/objmgr. The ultimate implementation of that object hierarchy has to reside in a DLL that exports certain functions that are defined in the according rc file. I believe they exist since LabVIEW 7.0 and some of the necessary methods for that DLL to interface to LabVIEW exported C functions seem to have been accidentially? documented in the LabVIEW 7.1 and 8.0 extcode.h file. Still trying to get something working here is a very tiresome exercise with lots of crashing and obviously involves external C programming. 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