Rolf Kalbermatter

QUOTE (Rajeswari @ Nov 30 2008, 06:31 AM) First a DLL alone does not help much really! It seems to be a combined COM/standard DLL, meaning it exports both a COM/ActiveX interface and a standard C function interface. It even seems to contain the selfregistration for the ActiveX interface so that you can register the DLL using regsvr32 "<path to your DLL". It might possibly even include the necessary typelib, that allows you after registration of the DLL to use that ActiveX interface from LabVIEW using LabVIEW's ActiveX interface. The C interface however, that you are trying to access through Call Library Node does usually not have any information about the actual interface. It just exports the function name and leaves the rest up to the caller. You can use the External Library import wizard in LabVIEW 8.2 and higher if you have the header file for the DLL and in 8.5 this wizard is even able to import more complex function prototypes but all automatic translation has to end somewhere and the import wizard usually chokes on very involved function parameters. This means not necessarily that the function can't be imported in LabVIEW using the Call Library Node, but it usually means that it can't be done without some complicated vodoo techniques that are out of question for anyone without very good C understanding. And someone knowing C good enough to be able to apply those voddo tricks will almost always chose to write an intermediate DLL that translates between the complicated C function parameters and somewhat more LabVIEW friendly parameters. So a DLL alone is of absolutely no help without the according header file if you want to import the standard C functions from a DLL using Call Library Node. And often the header alone is not enough either since the C syntax is ambigious enough that the meaning of some parameters can be only determined by studying C example code or reading a thorough documentation about the function (with the latest being seldom available). My advice if you are not a seasoned C programmer: register the ActiveX interface of the DLL and try to use that instead, using the ActiveX interface in LabVIEW. Rolf Kalbermatter

QUOTE (Gary Rubin @ Nov 21 2008, 10:45 AM) Not sure why it shouldn't and I think some collegues did that in the past. LabVIEW 7 for sure does run on XP and so should run on XPE too, provided you install a little more than the most basic XPE modules. Rolf Kalbermatter

QUOTE (skof @ Nov 27 2008, 05:29 PM) Another possibility is that you target the wrong application instance. Since LabVIEW 8.0 a LabVIEW process can have many application instances with one main instance and then one additional instance for each possible target in every single project. Of course they don't always remain on the same host (RT target in a project) and consequently have different IP nummers to open first. But when I was deploying a project to a cFP controller recently and tried to access a VI through VI server that existed in this project I got this error too. Solution was to explicitedly configure VI server in the target of my project to use a different IP port and connect to that. This did kill my performance though so badly that I had to abandone this approach. I guess there is a default VI server on a RT target (as I could connect to it) but a directly deployed application from a project gets instantiated in its own application instance that has to be enabled first. Rolf Kalbermatter

QUOTE (Blackbyte @ Oct 25 2008, 09:12 AM) Most probably you need to set the "prepend array or string size?" on the Write To Binary File to false as it is by default true. What this does is prepending a 32bit integer indicating the number of array elements (bytes in the case of a string) that follows and that is very useful if you stream multiple blocks to a file but not necessary for a single block and in the case of fixed file formats even catastrophic to do. Rolf Kalbermatter

QUOTE (Pollux @ Nov 20 2008, 04:55 PM) You don't usually change the cell when the user hovers over the cell but only when he clicks in a cell. That is fairly easy to do with the event structure and a mouse click event. Calculate the cell number from the mouse click position, make a numeric control visible and place it there in the right size and then you are more or less set. Personally I have used the array of clusters in the past too for such cases though Rolf Kalbermatter

QUOTE (Thang Nguyen @ Oct 28 2008, 09:23 AM) It's simply a byte stream like a LabVIEW string with the only difference that there is a different color on the diagram for it. It's contents are bytes, numbers and arrays packed together and the according format (for at least the published operations) can be reverse egineered frorm the diagram of the variaous Picture Control VIs. This is what Norm talks about in the begin of this thread and what he has done (just as I had about 15 years ago at some point). There is no secret about that, it's just a tedious work to do and in my case I do not have real documentation about that format anymore. Rolf Kalbermatter

QUOTE (Pollux @ Nov 25 2008, 09:25 AM) How would that work? An application can only close itself without some explicit and dirty Windows kernel API calls. Rolf Kalbermatter

QUOTE (pikro @ Nov 12 2008, 09:39 AM) You're obviously using it wrong because it does for sure work here. But I'm not going to upload a 1000 VI project! I'm pretty sure there should be an example to this effect in the LabVIEW examples though. Rolf Kalbermatter

QUOTE (mesmith @ Nov 11 2008, 02:43 PM) Additionally there is the possibility that msvcrtd.dll or one of its versioned siblings msvcrXXd.dll relies on yet other DLLs that are in debug versions and get installed with MSVC only. Rolf Kalbermatter

QUOTE (caspar @ Nov 25 2008, 05:11 AM) Quite likely. This behaviour in 8.5 was not a bug that got introduced but instead a change to the behaviour to make the .Net Interface in LabVIEW behave the way Microsoft meant .Net to be used. In earlier versions LabVIEW tried to be smart and locate dependant .Net components itself but I'm sure that opened a whole can of worms that was remedied by simply relying on the .Net behaviour itself. Rolf Kalbermatter

QUOTE (mesmith @ Nov 24 2008, 07:14 PM) Mark is completely right in all he says. The debug versions of the MSVC runtime libraries only get installed when you install Visual C or maybe an application with MSVC runtime support compiled in debug mode, although I'm not sure the debug version of the runtime libraries really belong to the redistributable part of Visual C, so such an application if not from yourself may be not legal. It's most likely a somewhat misleading error message in the shared library loader. LabVIEW has had traditionally a certain number of well known error codes. When adding a new subsystem the developer always had two choices: Adding a new error code for every situation or trying to find an existing one that matches the situation fairly well. Adding new error codes used to be a major hassle since all the necessary information had to be entered into the resource files of LabVIEW too which is a completely different work flow chain than editing the C source code, so the choice was usually towards reusing an existing error code. When LabVIEW asks Windows to load a DLL on its behalf Windows will fail the loading if a dependency can't be satisfied. The returned error code is sort of generic and there is virtually no way to get the information about what dependency was missing unless one would walk the entire import tables of the DLL and its dependencies. Translating OS specific errors into Framework specific errors is always a tricky and lossy business. Nowadays the errors are not as tight into the LabVIEW Framework itself so the choice is more often made to add subsystem specific error code ranges but the Call Library Node shared library loader code dates back to LabVIEW 3 and at that time priorities and possibilities were quite different. Rolf Kalbermatter

QUOTE (Paulus @ Nov 24 2008, 01:12 PM) That obviously avoids the alignment problem. Rolf Kalbermatter

The OpenG PortIO package allows to access port adresses as well as physical memory adresses. This release (v1.2) adds support for physical memory acccess and also removes the actual kernel driver file from the system directory on uninstallation. You can download+install this package using VI Package Manager. Just press the "Check the Network for Available Packages" button to refresh your package list.

QUOTE (jw666 @ Nov 13 2008, 11:10 AM) const char *name is a C string pointer. So configure the according parameter in the CLN as a String of type C Pointer. double is the C equivalent for a LabVIEW double precision floating point number. So this will need to be a Numeric parameter of type 8-Byte double. The * indicates it is passed by reference so set it to Pass: Pointer to Value. The other has no * so it is Pass: Value. What the actual string should contain is of course entirely to the device or the DLL or maybe even both. Rolf Kalbermatter

QUOTE (MJE @ Nov 8 2008, 10:24 AM) MJE's recommendations are all valid. The biggest trouble will be probably the lpEventAttribute structure. This should be either a NULL pointer or a valid security attribute structure. Since you are not likley going to create child processes of your LabVIEW process a NULL pointer will be fine so go with that and configure this parameter as an UINT32 (or if you use LabVIEW 8.5 or better use the new Pointer type, which will take care of adapting to 64 Bit pointers once LabVIEW for Windows 64 bit will become available) and assign it a value of 0. Also the two Boolean variables might be a problem too although I wouldn't expect them to cause the function to fail, just do unexpected things. In Windows 32 Bit every parameter is in fact passed as 32 Bit value on the stack but if you declare it as 8Bit it's entirely up to LabVIEW if it extends that parameter to 32 Bit before pushing it on the stack or if it just fills in the 8 Bits leaving the other 24 Bits at whatever random value they might be. This would mean that whatever you do pass in as Boolean value it is very unlikely that the function will ever see anything else but non-nul (or TRUE for that matter). Rolf Kalbermatter

QUOTE (professor_rumsdiegeige @ Oct 31 2008, 06:13 AM) No! LabVIEW for Linux simply does not contain any support for accessing .Net and hence Mono. It would also not be easy to do that since MS does not support compilation for Linux so even their .Net headers are simply useless for a Unix compilation of LabVIEW. Which would mean the LabVIEW developers would have to use Mono libraries and headers and since Mono is still heavily in development it would be very difficult to support that. LabVIEW as a precompiled binary can only contain compiled libraries and those libraries would contain code of the Mono development system used when compiling LabVIEW. That would mean it would only work with certain versions of Mono and would fail with older as well as newer improved version. All in all a lot of hassle for little gain so no I don't think it will happen very soon. Rolf Kalbermatter

QUOTE (DanielChile @ Oct 27 2008, 03:14 PM) Actually I haven't. Have been in communication about it at some time with them and you can request an evaluation version, so I think it should be fair. Rolf Kalbermatter

QUOTE (DanielChile @ Oct 27 2008, 09:11 AM) There are some Alliance Members that do actually sell their localization solutions. Some are more or less a VI library, others come with extensive support for text editor interfaces for importing and exporting the relevant strings into a text format that can be easily handled by a professional translater without any knowledge of programming, including LabVIEW itself. Toolkit type software: SEA Datentechnik GmbH, LabVIEW Localization Toolkit NI Resources http://zone.ni.com/devzone/cda/pub/p/id/99 http://zone.ni.com/devzone/cda/tut/p/id/3603 http://zone.ni.com/reference/en-XX/help/37...ng_labview_vis/ Rolf Kalbermatter

QUOTE (crelf @ Oct 24 2008, 09:22 AM) Quite what we do here too including traversal of containers like tabs and subitems such as ring control texts, but the translation files get soon difficult to maintain and therefore we also try to avoid it if possible. Also you often end up not only translating captions but also data elements itself and that is even more complicated to get right. Rolf Kalbermatter

QUOTE (dannyt @ Oct 23 2008, 03:07 AM) Before LabVIEW 8.0/8.2 I sometimes made a specific resize state in my state machine that actually explicitedly moved and resized all relevant controls according to the FP size. Quite cumbersome and not very easy to maintain but a big wow effect for anyone seeing how the controls always resized exactly in proportions to the screen size. With LabVIEW splitterbars this is actually quite a bit easier and more functional. Michael Aivaliotis gave a very interesting presentation on NI week how to use the splitterbar to actually get a seemless scaling user interface without the need to explicitedly set individual control sizes. Rolf Kalbermatter

QUOTE (Paulus @ Oct 22 2008, 06:56 PM) LabVIEW uses internal to the diagram whatever endianess the CPU prefers. only when flattening data to a stream or unflattening it from it (Flatten, Unflatten, Typecast, Binary File Read and Write) does it apply endianess conversion (in LabVIEW >= 8.2 by default, before that always) to make sure data is in Big Endian format on the byte stream side. So the data passed to your DLL is really in whatever format the CPU desires on which LabVIEW is running, which in your case is the same Little Endian format as what your DLL expects. My only explanation is that you interprete the data structure wrongly. While elm in itself is indeed a pointer it is not a pointer inside the main structure very much but the entire array is inlined into the main structure. This means you see the start of the data at byte offset 4 relative to the start of the structure. On some obsolete platforms (SPARC) the offset would be actually 8 since LabVIEW has to align floating point values to their natural byte boundary for the Sparc CPU to be able to access it without a huge perfrmance penalty but on Windows LabVIEW uses byte packing for all structures since the x86 architecture has little or no penalty for such access. Did you include extcode.h in your program? If not you have to add an explicit #pragma pack(1) before defining your structure and best reset it back to the previous by using a #pragma pack() after. Microsoft VC uses 8 byte alignment by default. Rolf Kalbermatter

QUOTE (LV_FPGA_SE @ Oct 23 2008, 08:38 PM) If you read this thread you will see that his complain against the world is that nobody wants to give him the job he would want. So what he really wanted to say here was probably more like: "Those who are talking about prostitututes don't get a job, just like me." However he fails to see that often it is not just what you talk about but also how. And nobody wants to get accused to be below "animal level" whatever that means . But with his bold and out of the blue statements it is both completely unarguable in a any sense as well as pretty unlikely to not feel accused :ninja: . Any critic is not only not answered to but simply overrun with all the same bold and out of blue statements again. Definitly not someone I would like as a collegue. Rolf Kalbermatter

Somethng that has bugged me a few times now and that I haven't found in here. So I'm adding it for documentation purposes. When single stepping with highlighting through a diagram in LabVIEW 8.2.1 I mostly see #0 as number of elements getting out of various array producing nodes in the text produced by highlighting mode where aan according probe shows clearly that there are elements in the array. Does doesn't seem to occur in 8.5(.1) anymore. Rolf Kalbermatter

QUOTE (Yair @ Jul 15 2008, 10:58 AM) It's definitly wrong! I would be not surprised at all if the first order wouldn't work as it is not a common feature for a server to change it's port number after it has started. But that setting the port and then starting does not work is really doing things backwards RolfKalbermatter

QUOTE (raymyster @ Oct 19 2008, 01:51 AM) It may or may not install in 8.5 I'm not sure. In general Toolkits should support a few earlier versions of LabVIEW but the category Toolkit is a bit stretching for the DSC module. But you are going to install a whole DSC system too that you may not want to use. The graphics itself will work in LabVIEW 7.1 too, the Image navigator and the DSC controls which are part of the LabVIEW DSC mocule will not howver. LabVIEW 7.1 was without proper license activation so there was never a way to download evaluation versions for Toolkits and such and the evaluation version for LabVIEW itself was a specifically compiled version of LabVIEW where certain features had simply been removed. Rolf Kalbermatter