Rolf Kalbermatter

QUOTE (dmpizzle @ Jan 9 2009, 04:28 PM) The LabVIEW Text Write function node has a mode selection (right click pop-up menu) called "Convert EOL". When activated the function will convert each instance of LF, CR, or LF/CR into the end of line identifier for the current platform. Each platform has its own native EOL with Mac using a CR, Unix a LF and Windows CR/LF. And I think that LabVIEW for Mac OS X still uses the CR as it is really a Carbon application despite the underlying Unix kernel. When you want to write a text with specific EOL you have to format it accordingly and disable above mentioned option in the Write Text function. Rolf Kalbermatter

QUOTE (Antoine Châlons @ Jan 10 2009, 06:12 AM) Option 3 was somewhere documented in old LabVIEW days (LabVIEW 4 or 5) but it seems it got somehow lost since, although it still works. Rolf Kalbermatter

QUOTE (mattdl68 @ Jan 8 2009, 05:39 PM) This is in the installed online help of LabVIEW for quite some time at least since 8.0 although with some small modifications in each version to adapt to changes and new features of the Call Library Node configuration. LabVIEW Help Menu->Search the LabVIEW Help: Index Tab: enter call library This will eventually get you to a topic under: Fundamentals->Calling Code Written in Text Based Languages->Concepts->Calling Shared Libraries (DLLs) It is about the meaning of the options in the configuration of the Call Library Node. But it won't help you with your previous question, how to find out in which order and with what parameters to call a particular API. Of course it is actually about calling an API that is typically written in C and the whole shared library concept is based on C too, so understanding at least the basic principles of C datatypes and their handling is really a prerequisite to be able to even understand what all those options and things mean. But that is not LabVIEW's fault, other than that it does not require you to know much about those things for programming some simple LabVIEW only VIs. For complexer programming it is even in LabVIEW more or less doomed, if you do not have some good basic programming knowledge, although the more C specific things you don't really need to know unless you want to venture into the Call Library Node or God forbid the Code Interface Node. Rolf Kalbermatter

QUOTE (Irene_he @ Jan 8 2009, 12:07 AM) No I think you are right. Except the person knowing 20% does not know that percentage . That person likely thinks to know almost anything he or she would need to do the task only to find out later that there was about 4 to 5 times as much to learn before they could actually succeed. The problem is that some people get discouraged half way through it and then abandon the idea. I have some of those projects too. Another quite common thing is that the last 10% of the work require 90% of the time. That is where most people stop. Rolf Kalbermatter QUOTE (mattdl68 @ Jan 7 2009, 08:44 PM) Thanks rolfk the link above will give you some history to my nightmare.......lol. What is confusing to me,is how to find the order of the dll's and functions to get what I need. There has to be some documentation out there that would give you some idea of the order in which to call functions.........one would think....lol I would think when trying to find USB devices using C++ they would need the order as well. Of course! And except from examples in the SDKs (and DDKs) and sometimes from Open Source projects you can investigate how certain things are done, that is where the creative art of programming starts. With trial and error, combinatorial logic, experience with certain types of APIs (if you have programmed WINAPI application, writing a MacOS X application can seem a really unlogical way of doing things and vice versa) and some sort of magic (I have often tinkered one or more days about how to get something to work, only to wake up one morning and having suddenly an idea that turned out to be the start of a solution), you go step by step about programming something. Programming in LabVIEW itself is not that much different but its on a much higher and more abstract level than tinkering with system APIs. And there is really no magic LabVIEW could employ to make working on system API level as easy as working on LabVIEW diagram level besides of having people like the NI elves and other third party developers write impressive intermediate level software such as DAQmx to make the work for the LabVIEW programmer more bearable. It's about the way your brain cells work and have been trained. On the same level, I've seen several brilliant system programmers cringe and falter at an attempt to produce a more than trivial LabVIEW application. Rolf Kalbermatter

QUOTE (jdunham @ Jan 7 2009, 12:45 PM) They never can be conflicting. TCP/IP mandates that at least one of these (TCP source address, TCP target address, TCP source port or TCP target port) must be different for any two connections. Otherwise the routing engine would get utterly confused. Since the listen socket (the device) uses a single address and port and the connections come from the same computer, the connection must be opened on different ports. Yes LabVIEW TCP Open Connection uses auto port selection and always uses a currently non used port for that. You can define a specific port to open but if that port is already in use TCP Open Connection will fail. And if the device allows multiple connections it will receive an individual socket for each incoming connection so it can easily determine from which source a specific command comes. If it can't handle multiple connection it will normally simply not accept new connections and the second and any further connection attempt will fail with a timeout. It could be also that the device principially does accept multiple connections but its execution engine is buggy in the sense that it can not handle multiple connections without creating a mess. This would be a design problem of the device. Rolf Kalbermatter

QUOTE (Val Brown @ Jan 3 2009, 05:05 PM) Well, theoretically. In practice the Windows API is sometimes very complex and the most difficult part is that it usually pulls in a very large part of the Windows header files and some of them do contain C preprocessor defines and C language constructs where the DLL Wizard parser simply chokes on. I've been writing a C header file parser in the past using LabVIEW and it was a major pain and still is not doing as much as the DLL Wizard parser can handle. So even if the actual function you try to import is not using complicated parameters it is quite possible to fail due to the pulling in of other Windows API headers that are undigestable for the parser. And if it is using complicated parameters then it will fail a lot of times anyhow. QUOTE (mattdl68 @ Jan 3 2009, 03:38 PM) Hi Irene. Thanks for the info. I looked into doing a wrapper. But i don't Know c that well. I was trying also to use the VISA develoment wizzard. The wizzrd had errors trying to setup the setapi.dll. The VISA wizard is not about helping you call DLLs but about creating inf files for accessing VISA devices including USB devices. However for USB devices they should not be handled by an already installed or standard Windows driver as then VISA can not gain access to it. You probably meant the Shared Libary Import Wizard and here you obviously need to point it to the right header file. In the case of the SetupDi... functions this would be the SetupAPI.h. Functions not defined in there but being exported by the SetupAPI.DLL (all the CMP_ and CM_ functions in your other screen shot) will of course cause errors but should not affect the SetupDi.. functions. However it all could still fail due to unparsable constructs in the SetupAPI.h file or in other depending header files. QUOTE Correct me if i"m wrong, even using c++ you need to know thr order in which to call the functions. For example...say i want to find all devices currently connected to the USB? What is the order of doing that? i'm assuming there are some outputs of some functions that feed the inputs of other funtions. Is ther some documation for this? Yes MSDN and the Windows Platform SDK. MSDN is mostly about the function prototype and documentation and the Platform SDK (PSDK) contains both the headers and C code samples how these functions can be used. QUOTE the SetupDiGetClassDevs asked for a flag, Dword. DIGCF_ALLCLASSES is one of the fags. Is this a string? The flag ClassGuid is it a key which looks in the Ini file supplied by manufactuer. To get the device id (number) but seeing for know I what all devices connected. This should be set to null. So would I input a string constat(null) or a 0(U32) Since the flag is a DWORD it must be a integer number or bit flag. What numeric value corresponds to the Preprocessor symbol DIGCF_ALLCLASSES you can sometimes lookup in MSDN and otherwise you have to search in the headers of the PSDK for it. A GUID is a structure of 16 Bytes length as you seem to have been told already. This and anything else about datatypes can be also found on MSDN or in the headers of the PSDK. The function expects a pointer to that. If you need to pass here a NULL value you would configure it as uInt32 (or (Un)Signed Pointer-sized Integer in LabVIEW >= 8.6 which will take care about adjusting for the different pointer size if you ever move to LabVIEW for Windows 64 bit) and then pass in a 0 integer. QUOTE (Val Brown @ Jan 3 2009, 08:14 PM) It is impressive to me how frequently that Wizard simply fails. Welcome to DLL Hell. Ever written a C compiler? Try and you will understand! I admire the courage of the person not only attempting the task of creating the DLL Wizard (I've written a somewhat less exhaustive C header parser in LabVIEW for another project) but also adding it to the released version of LabVIEW. How it got past the release manager I'm not sure but that person probably had no idea about how difficult a good C parser is, so he or she believed it to work fine after being shown some successful imports from not to complicated APIs . Since it will be almost impossible to remove that tool now, it will stay there but I'm not sure there will be enough support for it once the father of this project moves on to other tasks. Rolf Kalbermatter

QUOTE (Cool-LV @ Jan 5 2009, 07:54 PM) You can get that lib from the aformentioned code capture tool. The clipboard library is only a utility to the bitmap library functionality so said example should actually have been put in the bitmap lib instead of into the clipboard lib. Ahh well, if everything would be perfect! But then it comes for free, doesn't it? Rolf Kalbermatter

QUOTE (Cool-LV @ Jan 5 2009, 03:51 AM) Here is the clipbrd.llb file from the Code Capture Tool enhanced with three functions to handle CF_HDROP. LabVIEW 6.0 format http://lavag.org/old_files/post-349-1231192068.llb'>Download File:post-349-1231192068.llb Rolf Kalbermatter

This is a crosspost from http://forums.ni.com/ni/board/message?boar...ding&page=5. We finally did a definite release of the OpenG LVZlib library. There are no real changes to the library itself apart from some documentation updates and cosmetic changes but it is now official. For a more detailed list of changes in this new version relative to 2.3 you can refer to http://wiki.openg.org/Oglib_lvzip-2.4 The Windows, Linux and MacOS X version are all updated and seem to work just fine. Sorry for the Mac Classic guys but I saw no opportunity to recompile for Mac Classic targets yet and we do probably not intend to build for that target anymore unless there is some real demand. While support for VxWorks has been added it has not been tested on VxWorks targets yet as I still haven't one available to play with. The OpenG package can be downloaded here and is best installed using VIPM. For VxWorks support you should ftp the according lvzlib.out to the controller into ni-rt\system, from the correct subdirectory (vxWorks82 for LabVIEW 8.2.x and vxWorks85 for LabVIEW 8.5.x and 8.6) inside the lvzip directory created where you installed the package. As already mentioned this should now work for following targets: Windows, Pharlap RT targets lvzlib.dll VxWorks RT targets lvzlib.out Linux targets lvzlib.so MacOS X lvzlib.framework Rolf Kalbermatter

QUOTE (lenny wintfeld @ Dec 29 2008, 04:53 PM) Basically it is meant as a library of template icons. You select the icon of your choice, then go to Edit->Copy or press Ctrl-C, then go to the icon editor for your own VI where you want to use this icon as a base and in there you make a Ctrl-V or Edit->Paste. Now you can start to customize your icon the way you want it such as adding the Instrument Prefix. The Icon256.vi in itself has absolutely no runtime operation at all and is not meant to have one either. Rolf Kalbermatter

QUOTE (Tomi Maila @ Dec 29 2008, 05:50 AM) Only if Windows or whatever OS you are using is adding that leap second in its time base. Question is: will they do so or just silently ignore the leap second? Edit: According to http://www.meinberg.de/english/info/leap-second.htm at least Windows will not do leap seconds correction on its own. Of course if you do time synchronization you will see the effect anyhow, however if you do that your application should be prepared to deal with incontinueties in the returned time anyhow since the synchronization can cause jumps of more than one second whenever it happens. Rolf Kalbermatter

QUOTE (malani @ Dec 29 2008, 08:06 AM) What is inefficient about that? It's exactly how the Substitute copy for Original is implemented only without the delete afterwards as the original file remains on disk. You do need to think about feelings you have. Just because something does feel inefficient does not mean it has to be so. If it works and does what you want, why going to try to make a supergalactic solution instead? Not even a NASA budget could help you there Rolf Kalbermatter

QUOTE (vugie @ Nov 17 2008, 05:42 PM) You didn't search good enough. It is documented in a few posts at least on forums.ni.com but probably even here, and quite a few times on old Info-LabVIEW although that may be a bit harder to search nowadays. It is an issue as far back as I can remember (LabVIEW 3.x or so). Rolf Kalbermatter

QUOTE (romeo @ Dec 22 2008, 11:39 AM) A common problem and you will find many links here and on forums.ni.com describing that. The reason is that the image inside the ActiveX control is not controllerd by LabVIEW but by the ActiveX control. Simply put there is no simple way for LabVIEW to tell the ActiveX control to render itself into an offscreen context so that that context can be turned into an image and then send over the web. Rolf Kalbermatter

QUOTE (carlover @ Dec 24 2008, 06:18 PM) Well there always is but I doubt you want to go to that length. It would probabply mean to call the JPEG (or whatever format you have) DLL directly with two memory buffers to decompress from and into and then using the IMAQ GetImagePixelPtr function to directly copy the entire decompressed buffer properly into the IMAQ image. All this would be best done in an external code function written in C. You can of course also use the IMAQ ArrayToImage function instead so you have not to worry about getting the correct memory offsets into the pointer but that function is considerably slower. Rolf Kalbermatter

QUOTE (neB @ Nov 18 2008, 09:37 AM) Ohhh! I should probably look by more frequently . Only just now happened to see this. Thanks Ben and everybody else. I guess I moderated my appearance a bit lately. Seems like kids have that effect. But there are a lot others who are doing a better job than I could ever do in many of the more modern topics such as *OOP. I'll probably continue to contribute to some extend but the times where I could post daily are definitely gone. Happy Christmas and a happy new year to everybody and keep the wirework up! Rolf Kalbermatter

QUOTE (xavier30 @ Dec 18 2008, 08:49 AM) I can't help you with that. Makefile creation is a rather tricky business even if you only want to target one OS. Cross platform is simply beyond my knowledge. The way I do it is using MS VC .dsw project files for Windows, simple Makefile for Linux, Xcode project file for Macintosh and last but not least a modified Unix Makefile.vxworks for VxWorks creation. Trying to figure out the perfect settings and everything to create a cross platform Makefile is a noble desire but I have better things to do with my time ;-) Rolf Kalbermatter

QUOTE (Wedge @ Dec 24 2008, 01:49 PM) Your XyzWpr class is probably not instantiable through a class factory of your DLL but instead only available as subclass of the main object hierarchy. Try to connect a property node to the CurPosition property of the main instance instead for instance. It could be likely the same class (big guess from my side though) and see what you get there. In order to be able to instantiate classes as top level classes they need to be supported by the class factory of the automation server (your ActiveX DLL). For many subclasses that makes little or no sense since they are only meaningful in the context of a higher class. Rolf Kalbermatter

QUOTE (Ton @ Dec 23 2008, 01:01 PM) Most likely there will be no difference for a user of the library, unless you use the Mac or I do come across some bug until then. The Mac at least on newer OS X versions has an issue with long pathnames and until I had time to test that a bit more I did not want to create the shared library. Besides I do not have an x86 Mac so creating the shared library has to be done by others (Jim Kring will probably go to do that). For now it is mostly to give the opportunity to others to test the VxWorks version since the last changes to the library were in fact to support that based on very helpful feedback from Brian K from NI. So yes there is a chance that you could encounter a bug when using this version (but that is true for any software released or not :laugh: ) but I do not intend to change anything in terms of functionality, VI interfaces nor design of the library for the final release. Rolf Kalbermatter

I have personally only ever used my own ODBC based library. I can't really comment if it is fast as I have no comparison but it was never slow for what I needed it for. I have implemented some specific features in that library to fetch one or more rows at one time to reduce the network roundtrips the ODBC driver has to do for a query. There is actually still room for improvement in that part but the entire interface is written in C and this part is something that gets very messy very fast once you consider to support not just one specific ODBC driver but want to be compatible with as many as possible. If you are doing lots of updates however this library wouldn't help much as these have still to be executed as SQL statements since I haven't found time to add support for parametrized SQL updates and the priority for this is way low on the list. The fastest way to access an SQL server is quite likely through its native API. There is a DLL interface to the Microsoft SQL Server API that does avoid any issues with intermediate standardization software layers such as ODBC, ADO. DAO, ADO-.Net. I have no idea how easy if would be to interface to that API using the Call Library Node but suspect that there would be some intermediate code required or at least very helpful, to translate between the SQL Server API and a more friendly LabVIEW API. The disadvantage of this approach is that you will be tied to SQL Server for the rest of your life if you use its own proprietary API. Some remarks to some other things mentioned so far: LabSQL, the Database Toolkit and just about any other LabVIEW database support library out there does use the ADO ActiveX interface. They may implement certain things differently such as using the mentioned GetRows method or iterating through the rows instead, support certain operations or not but the basics of all them is in fact ADO ActiveX. As to the missing of the GetRows operator in .Net. I think John is using a technique he got from the mentioned blogs from Brian Tyler where he does the actual extraction in an external .Net component written in VB or VC .Net to avoid exactly the huge overhead of having to iterate through the entire rowset from LabVIEW which due to its dynamic interface to .Net has a certain overhead for each invocation of a .Net method. Rolf Kalbermatter

This is a crosspost from . This is a prerelase version of the newest sources from the sourceforge CVS repository. All public symbols should have been prepended with lvzip_ to avoid name collisions with the already defined functions in the VxWorks kernel. The Windows and Linux version are also updated in that way and seem to work just fine. Sorry for the Mac guys but I saw no opportunity to recompile for Mac targets yet and there is one outstanding issue with this new version that needs some more testing. This has not been tested on VxWorks targets yet as I still haven't one available to play with. The included OpenG package can be best installed using VIPM. Download File:post-349-1230024275.ogp For VxWorks support you should ftp the according lvzlib.out to the controller into ni-rt\system, from the correct subdirectory (vxWorks82 for LabVIEW 8.2.x and vxWorks85 for LabVIEW 8.5.x and 8.6) inside the lvzip directory created where you installed the package. As already mentioned this should now work for following targets: Windows, Pharlap RT targets lvzlib.dllVxWorks RT targets lvzlib.outLinux targets lvzlib.so MacOS X, x86 support will follow. Rolf Kalbermatter

QUOTE (Minh Pham @ Dec 21 2008, 10:47 PM) Well said! Rolf Kalbermatter

QUOTE (Wedge @ Dec 21 2008, 07:30 PM) I'm really sorry. But I have not used the PCDK nor even seen it so I can be of little help here. Basically ActiveX has two different types of interfaces. one is the Automation interface and the other are ActiveX Controls. The first you have to instantiate using Automation Open and the second is instantiated at the momen it is loaded into an ActiveX container. At least under .Net you also have static interfaces. They do not need to be instantiated (created) as they are not an object in the normal sense but simply a collection of methods to do something that is not inherently tied to data that the object would maintain. For an Automation Interface, and I'm sure the PCDK does implement such an interface, you usually have an object hierarchy. The root object is usually something like IApplication or something like this. You always have to instantiate that object using Automation Open in LabVIEW. Once opened you usually have methods or properties in that interface that return among other things also references to subobjects from that object hierarchy. These objects you do not have to instantiate again since that would be the task of the object who returns an object reference. However just because you have opened a root object reference does not mean that you can add additional Automation Refnum controls in your application and connect them to subobjects interface types and expect them to be vallid. The connection to an interface only defines what methods and properties that refnum can provide but does not yet create a valid object reference. You only get a valid object reference from either Automation Open or another already instantiated object in the object hierarchy that returns an object reference. Rolf Kalbermatter

QUOTE (iannicholson @ Dec 8 2008, 01:25 PM) This protocol is called SRTP and is indeed proprietary. However it is based on the older serial port protocol which is documented in the programming manuals and also through some unsupported Visual Basic examples from Fanuc itself. I have recently written a VI library to control Fanuc Controllers over the LabVIEW build in TCP/IP functions. It works well for what we had to do but is far from throughly tested. I really couldn't recommend anyone to use it who isn't well into low level programming including TCP/IP protocols and since there is no real documentation about it I will refrain from posting it here. Rolf Kalbermatter

QUOTE (AnalogKid2DigitalMan @ Dec 8 2008, 09:59 AM) They probably are but there will likely be some capacitive coupling. This can be sometimes problematic for higher frequencies. Rolf Kalbermatter