Rolf Kalbermatter

It's definitely NOT possible. ActiveX is a monster that builds on Windows 3.1 OLE technology and making LabVIEW create ActiveX controls would be almost impossible. ActiveX Automation servers might probably work but why settle for such a crippled beast? As already mentioned you can create .Net assemblies but that is not a .Net control either. Making LabVIEW GUI elements embed into Windows .Net and ActiveX GUIs is only really possible on the lowest platform API level by embedding entire LabVIEW panels into other windows.

Can't really help you with that (well I could theoretically but don't have enough time currently to spend on these things). But if you want to go multiplatform you definitely want to write external code in form of a shared library. Maintaining such platform specific code in the diagram is a major pita. So I guess DLL/shared library it is going to be . Also additional bonus points/troubles for making the that code NOT depend on platform specific icon resources .

Well I guess they all are possible venues, but!!!!! 1) is best if you have the entire algorithm available and also have some good test cases. Porting the algorithm is one thing but proofing it does indeed do the same thing as the original is quite a different beast (and can often take up a lot more time than (re)writing the algorithm itself). 2) Depending on the algorithms used and the way the code is written this could be a complete rewrite as well maybe even employing a different algorithm (if possible) to actually allow parallelization. 3) Quickest and dirty solution 4) This is probably in terms of efforts quite a bit smaller than 1) and 2) but of course depends on the algorithm used if there is really much potential to gain performance.

No Ton already mentioned it although didn't say so specifically. For the libraryname you enter <name>.* and make sure that the .DLL and .so are in the same directory on the respective platform (they can be both present on both platforms but don't need to be). Then LabVIEW will replace the * at the end with whatever prefered shared library extension for that platform and load the resulting library.

Are you sure you have 32bit LabVIEW installed and not 64bit? You can't call a 32 bit DLL from a 64 bit application or vice versa. They live in completely different environments and have no direct access to each others memory. What do you mean with the DLL returning 0 for the reference while the Automation Open crashes? Is this DLL an ActiveX DLL or a normal DLL, accessed through the Call Library node? Otherwise there might be a problem with registration of your component/DLL.

Actually the issue here is most likely that sys.path is not initialized or at least doesn't contain the directory where your socket module is. LabPython does not do much of environment initialization when you create a session (and the Python script node is also simply creating a session implicitedly). So whatever the Python core doesn't find on its own you need to setup yourself. For the script node you would need to add the module directory path to sys.path and for a programmatic session you could execute a statement that sets sys.path accordingly before you execute a script that tries to import things.

Another workaround I use occasionally is to include a property node that access some property of a front panel element. This is a NI sanctioned way going back to LabVIEW 4 or so and I suppose they will not break that intentionally, even-though they may wish they never had used that workaround anywhere.

The OpenG Pipe Project does just that. It is a LabVIEW Library that replaces the System Exec function and returns pipe refnums for the three standard IO interfaces and functions to read and write to those refnums. The project hasn't been released yet as I consider it not entirely release quality but it does work for me and I have actually used in in several of my projects already. Since there is no officially released package yet you can't just download it through VIPM from internet. But here is a copy of a package you can install using VIPM. oglib_pipe-1.0-1.ogp

I heard the ADI Blackfin Embedded Toolkit is going to be discontinued. I'm sure you can still get a version if you have inside contacts but they are not going to develop it further and support is probably going to be minimal.

Can someone post the labview.lib file from the cintools directory from a LabVIEW 2009, 64 Bit for Windows installation? I need that to make some compile test for a 64 Bit version of the ZLIB Tools DLL, but haven't a 64 Bit machine handy where I could install the 64 Bit version of LabVIEW.

Well, there has recently been some work on the underlying ZLIB library to make it ready for 64 Bit. There is also a ZIP library on top of that that will require some careful review for 64 Bit compatibility. I think there might be a few issues there. Then there is also the VI library which would need to be updated to use pointer sized integers for some of the parameters. Last but not least this all needs to be compiled with a 64 Bit ready Windows compiler. I guess one of the Visual C Express Editions might do the trick but I haven't done any work in that direction yet. I have plans to incorporate the recent ZLIB 1.2.5 version into it. This is mostly a simple replacement of existing files in the source code and should help to make that part fully 64 bit ready. Then I will need to setup a working 64 Bit compiler tool-chain somehow and get a bit familiar with it. The real work is trying to find areas where 64 Bit might cause issues. Even if the code compiles fine and seems to do work, that is no guarantee that all the critical areas are fine. So all in all in it is quite some work and even more testing and I'm at the moment a little tied up with other stuff. I do intend to work on this if nobody else beats me to it, but it is for sure not just a recompile. And since the code changes in some ways there will be a new release of all shared libraries necessary and for true 64 bit support pre LabVIEW 8.0 support might have to vanish.

And I'm not going to read all caps text. sorry!

If the DLL call and ActiveX call are both UI threaded (ActiveX as said is most likely, DLL depends on the Call Library node configuration but if it is a driver you haven't written yourself I would be vary to change a possible UI thread setting to re-entrant as that could cause all kinds of weird problems in the DLL if its functions aren't explicitly written to be re-entrant) you get most likely following scenario: Since the ActiveX call takes a certain amount of time, LabVIEW can't interrupt it midway to switch to the DLL call and let it take over the same UI thread. Once LabVIEW hands over control to an external code (ActiveX or DLL) it can only wait for that code to return code back to LabVIEW before doing anything else in that same thread. There is not a single way around it. I can give you a solution that will work. Create two LabVIEW executables, one calling into the ActiveX component and the other into the DLL, and let them communicate through Inter-application Communication together. That solves the problem since both components now reside in separate processes and will be simply multitasked by Windows itself. Changing the Call Library Nodes to run re-entrant might be a solution, but without knowing the underlying DLL code I would never make such a change myself. If it is not set re-entrant this has most likely a reason. It could be just an omission from the actual programmer but the chance that the DLL uses global variables and resources between functions without protecting them explicitly is very high and in that case changing the VIs to allow re-entrant calls could in the best case lead to crashes in the worst case to strange and almost impossible to debug effects. One other option is to change the Call Library Node to be re-entrant and assign all Driver VIs to a specific execution system. Now you go into vi.lib/utility/sysinfo.llb/thread config.vi and run it. In that VI set the execution system you have chosen to assign to all driver VIs to only have one thread. This will likely work fine but has the disadvantage that the thread configuration is not part of the VI but of the LabVIEW runtime setup. So you will have to make sure to add the according lines in labview.ini, that this change will create, into any executable ini file as well as any other LabVIEW development system ini file that you may use, such as other LabVIEW development versions you may use or other LabVIEW installations on any other machine that wants to make use of that library.

Go into VI settings (File->VI Properties) and in there select the Execution section. In there enable reentrant Execution and read some online help to understand the effects and possibilities of the two options in there.

It's a long time ago that I have worked with it. Back in the first half of the 90ies of last century when working at NI in Switzerland, we had the entire lead tracking, inventory and invoicing in Filemaker, based on a system developed internally by some NI fanats :-). And no, corporate did not use that system, it was clearly only for the smaller oversea branches! I was regularly making modifications and extensions to it to add new features and ways to track things. At that time Filemaker was truely special as you did not really write a database system in it but instead designed (drawed) it, so it was much more similar to LabVIEW than any other database at that time. Is it easier to use than a database you already have experience with? No certainly not! But it was quite simple to do database systems with it, even relations between tables were possible although it wasn't exactly a full featured relational database back then. I'm not sure I would recognize the current version of Filemaker in any way though as I assume it has come a long way since, just as LabVIEW which has changed from version 3.0 at that time to version 9.0 now.

I'm not sure if you use some words a little unclear but the Control Online Help node in LabVIEW is the way to go, and yes you have to use help topics (LabVIEW calls it key) to jump to a specific place in the help file. That is how things work and how Microsoft (and other systems) have decided that help should be.

No the Copy function calls more or less directly the Windows API CopyFile() from kernel32.dll. So it is likely that the network provider for your shared directory has some problems with the underlaying network transport mechanisme. I would think it points towards some badly configured networking parameter which might be hard to track down as Windows tends to try to hide all kinds of things from the user nowadays, supposedly to not confuse the average user, for me sometimes rather frustrating as one needs to get all kinds of extra tools and utilities to get at the cause of such problems.

The Call Library Node has its own threading configuration that allows you to select that the DLL function is either called thread safe from the UI thread or in reentrant mode in whatever thread the calling VI is executing. If you have the UI Thread selected in the Call Library Node you can put the VI in whatever execution system you want but in order to call the function LabVIEW will switch to the UI thread first. I believe that most ActiveX nodes have to be called thread safe at all times, so they will execute in the UI thread anyhow (since most ActiveX components are specified to be apartement threaded, which is to say that an application should always call the Active X component from the same thread and the UI thread is the only thread in LabVIEW where this can be guaranteed without a very complex thread configuration system that nobody would understand.

Read my post and try to understand it. Also make use of the right click popup option on the Call Library Node!! There you will see that your function prototypes are simply way off as they are now Your header prototypes should more look like this: #ifndef STRUCTURE_H#define STRUCTURE_H#include "extcode.h"typedef struct { int32 dimSize; int32 elm[1];} IntArrRec, **IntArrHdl;#if defined(__cplusplus) || defined(__cplusplus__) extern "C" {#endifBOOL WINAPI DllMain(HANDLE handle, DWORD, LPVOID);_declspec (dllexport) int trial(IntArrHdl);_declspec (dllexport) int string_to_char_array(char *); // passing as CStr frm LabVIEW_declspec (dllexport) int string_to_char_aray_as_handle(LStrHandle); //passing string as an array handle#if defined(__cplusplus) || defined(__cplusplus__) }#endif#endif The "#if defined(__cplusplus) || defined(__cplusplus__)" preprocessor defines will prevent the compiler from decorating your function names with the useless C++ parameter signature.

You mix two very different things together here. The first sentence is in fact a little outdated and only telling you half the truth although technically still correct. Because you can pass LabVIEW native datatypes to DLLs since about LabVIEW 5 too. That is when they added the "Adapt to Datatype" to the Call Library Node and since then the CLN is in fact equivalent in this aspect to CINs. So the sentence is right that CINs get the native data passed to it but forgets to mention that that is possible with CLNs too, and this sentence is in fact a remainder from the time when CLNs indeed did not have that option, due to system limitations in the at that time supported platforms including the Windows 3.1 and Mac OS Classic versions of LabVIEW. The second talks about structures containing C array pointers which you can get sometimes when calling existing shared library APIs. Since LabVIEW does not represent arrays and strings as C pointers there is no simple way to create such structures in a LabVIEW diagram. But if you do create the DLL yourself, you are of course free to define the type of your function parameters and in such a way can use the LabVIEW native datatypes for your shared library function parameters by choosing Adapt to Type. This is an choice you do not have at all with CINs as they ALWAYS receive the parameters as native LabVIEW datatypes. So it is not that CINs give you something you do not have with the CLN too, but that the CLN also allows you to call many API functions directly that use C array and string pointers as parameters. But this only works if the C pointers are directly function parameters, not when they are embedded inside clusters you pass to the API. As last remark a handy trick when creating CLNs using the Adapt to Type feature or any of the LabVIEW native datatypes such as String and Array Handles: 1) Wire up the Call Library Node with the datatypes you want it to have 2) Right click on it and select "Create .c File" 3) In the file dialog select a file name to write to and LabVIEW will write a C prototype with all necessary parameter typedefs and the extcode.h include to disk so you can go on and copy/paste it into your C source code to be sure to start with the right prototype.

[quote name='prashant_bhutani' date='24 May 2010 - 06:50 PM' timestamp='1274723458' I am passing a null array as a parameter from LV but when I am looking at the indicator, it is not showing any result even for values/elements less than 10..... If i pass an array with some elements, the indicator is showing values upto those corresponding elements only...... one last thing is using (*arr)[0]=10 is a good idea??? Look you can go on as long as you want to insist that a LabVIEW array handle is simply just an int **. And it will keep crashing because it is NOT! A LabVIEW array handle is a pointer to a pointer to a structure that contains as many int32 as the array has dimensions, and where the actual size of each dimension is stored, followed directly by the actual array data inlined into this structure. Unless you do it exactly like this your C code will try to treat it in a very different way than what LabVIEW gives you. Or you pass the array as C array pointer. Then it is simply a C pointer and NumericArrayResize() has absolutely nothing to do with it. There is no other option in between these two Illegal access doesn't always have to crash immediately. Its effects can vary from an immediate crash, to a delayed crash, to a crash only when you exit LabVIEW to no crash at all, but some data in LabVIEW could be corrupted so either LabVIEW suddenly gives you somewhere seemingly bad results or if you save your VIs after that they might be corrupted beyond repair. The immediate crash only happens if the illegal memory access happens beyond any currently allocated memory for the process, the delayed happens if you overwrite LabVIEW data that it will try to access sooner or later NumericArrayResize() does work properly on your int** pointer since it is in fact a handle that is passed into your C function from LabVIEW, despite your incorrect C datatype in your function prototype, so NumericArrayResize() can operate on it with no problem. The possible crash could however happen after index 10 already in your example because you resized the handle to 10. If you pass in a longer array then it likely will not crash before it passes over the original length, because a resize to a smaller size will often be done inplace to save CPU time as otherwise the entire data has to be copied. But there is no guarantee that such a resizing will always happen inplace and you should never assume it does. But the returned array in LabVIEW should really show empty since you overwrite the first integer with its index which is 0 and that happens to be the length element in the LabVIEW array handle. LabVIEW only looks at the dimSize element to determine the length of an array. And if it says 0 in there it takes it as zero element array! It does not matter if you have NumericArrayResized that handle to 2GB or whatever, if dimSize is 0 the array is 0 length as far as the LabVIEW compiler is concerned and finito. If it shows you still all the initialized array elements then you do something different than you have told us so far and you will need to show us the entire C code AND the VI in order for us to give you any more details

I assume you call the trial() function from the LabVIEW diagram using a Call Library Node. In that case you'll have to configure the parameter to be an Array passed as Handle and the function prototype will look like this. typedef struct { int32 dimSize; int32 elm[1]; } **MyLabVIEWArrayHandle; _declspec (dllexport) int trial(MyLabVIEWArrayHandle arr) { MgErr err = NumericArrayResize(iL, 1, (UHandle*)&arr, 10); if(err == noErr) { ........ Now you can go on but need of course to make sure to: 1) not exceed array elm[9] as the array does only contain 10 elements 2) make sure to assign the dimSize element the right value (for instance 10) before returning to the caller

VISA Clear is in fact not really about flushing host data buffers but some sort of SCPI operation. For GPIB it issues the Selected Device Clear GPIB bus command, for USB TM Class devices (Instr Resource) it sends the INITIATE_CLEAR and CHECK_CLEAR_STATUS commands on the control pipe. For RS-232 it does indeed flush the buffers, sends a break and flushes the buffers again. So I'm not sure it will clear the host buffers of the connection in all cases. For that you have the VISA Flush IO Buffer node.

And I don't have psychic powers to see what you are doing so I can't give you any advice here!

This post is unstructured to the point of complete incomprehensibility. You start with NumericArrayResize/SetCINArraySize and then go to a completely different topic. You do not provide any code that shows your problems with the original problem so all I can offer to this aspect is following: If you haven't found anything sensible about NumericArrayResize in your search you have simply not searched enough and probably not at the right places. Google should be able to find quite a bit about that but the ultimate place to go and search for this information is www.ni.com who incidentially are the makers of LabVIEW and have a lot of online support resources available. NumericArrayResize() is required to resize LabVIEW array handles. SetCINArraySize() does similar but can only work in a CIN as one of its parameters is the parameter index to the CIN so that the function can determine the datatype of the parameter and only a CIN code resource has the necessary infrastructure to provide this information. But as you should have read elsewhere, CINs are old legacy technology and should not be used for new designs, since shared libraries (DLLs) work just as fine and are much easier to maintain and support. As to your second problem, your strt is a completely LabVIEW incompatible C structure. LabVIEW represents arrays (and strings are really just special byte arrays) as a handle and that is something VERY different than a C pointer. So you can not pass an embedded string pointer inside a structure (cluster) from a LabVIEW diagram as you try to do. If you want more detailed information you will have to make some more effort. Show us what you have tried and doesn't work. And don't talk in a single message about one problem and suddenly switch in the same message over to a completely different problem without explaining yourself in detail.