Rolf Kalbermatter

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.

Unless the OP is using some special features of the 6220. Please note the difference between USB-6210 and PCI-6220. This is not just for gimmicks . From my experience there are differences in the number of externally available signals, DIO capabilities 24 DIOs against 4 DI and 4 DO, and some internal line routing possibilities between these two devices. If you just use analog input, chances are very high that you only need to select the new device identifier in the DAQmx channel control for the Create Task VIs.

Captions should probably work too :-)

Reading your first Info-LabVIEW comment I certainly was thinking, man he is really making an elephant out of each tiny VI. But with this explanation I fully agree.

Complicated to use the ZoomFactor property??????? All the heavy weight lifting is internally done by LabVIEW for you and you feel it is complicated!

TcAdsDll.dll is definitly an x86 shared library and as such not loadable on an ARM or RISC Windows CE system. A quick Hex Editor look at TcAdsDllCe.lib seems to show that it references the TcAdsDllCe.dll and as you can see that is different than the TcAdsDll.dll you have in that archive. Also I'm not sure you do need the lib file at all when porting a LabVIEW library from your host system to an emebedded device. The normal opeation is to create a stub shared library for your host platform (Windows development machine) that has the same name and exports empty functions of all the functions you want to use in your embedded target LabVIEW application. Then you create Vis accessing this stub library through the Call Library Node. In this particular case you may even be able to skip the creation of the stub shared library and simply rename the Windows TcAdsDll.dll to TcAdsDllCe.dll to create on your Windows system the VIs to deploy to your embedded target. You still will have to make sure to deploy the shared library to your target that is compatible with your target and not your renamed fake DLL. This renaming could however fail in some ways if the DLL internally has code that somehow relies on its own name. Maybe you are going this in a completely different way that I'm not familiar with, such as the C inline node, but then you still will need to make sure you use the right shared library that matches your import library.

A full redraw is required for any overlaid control. But modern controls have extra overhead since they all use alpha shading which is a rather costly screen update operation. So you can say overlaying controls that update frequently is always a rather bad idea, but if it involves "modern" controls it is even an order of magnitude worse.

Bug?? Well, I would rather call it a limitation of the used underlying MESA library for rendering the Alpha shading of the modern controls.

If this question is how Index Array could do it, it's the same answer as before: This is not an XNode but a native built-in LabVIEW primitive. Using LabVIEW's internal C code, there is nothing that could not be done, but that interface is sadly enough not accessible at all from outside the LabVIEW source code.

I noticed this happening to all image attachments on LAVA lately. Must be a misconfiguration on the IP-Board software and I guess someone should alert Micheal about this.

Well I'm not sure if XNodes can be grown manually, but I do know that the Build Array node is NOT an XNode. It's a native node and is directly implemented in C inside LabVIEW.

Most likely this is because of the name decoration Visual C uses by default for WINAPI functions. Those functions have in fact by default (but it can be suppressed) an @n appended where n is the number of bytes the function takes on the stack for parameters. LabVIEW has been smart enough to accept undecorated function names(just as it also accepts prepended underscores which is the default name decoration for cdecl functions) and map them to the according decorated name for ages. Apparently they added in 8.6 the smartiness to use WINAPI automatically when the function has this decoration. I guess it can byte your ass as you have found out, but it is not a bad improvement. Of course the backsave feature would be even better if it knew this smartness too, but I have a feeling, that may not have been foreseen in the backsave feature, so it may not even be possible without a lot of extra work.

I haven't tried this but would strongly guess, that this is really just a Windows feature and by coincidence rather than by design. If it was designed that way they certainly would have made it more user friendly.

sorry I'm working on my network library to allow clients to communicate with them over SSL before starting to work on them themselves .

I have also gone the path of (very simple) LabVIEW installers. It works quite nice and when I did it in LabVIEW 7.1 I even could make it self contained by only copying a handful of LabVIEW runtime files into the same folder as the executable itself, so that it would work even with no LabVIEW runtime installed. Doing the same in newer LabVIEW versions gets however increasingly difficult and having to run an installer first for the LabVIEW runtime to be able to run an installer then for your application is not a good option . Another application I have worked with is InnoSetup. Advantages: Free, powerful, fully scriptable. Disadvantage: if you need to do anything non standard you have to write a script in a Pascal like language.

Very nice! You've found the menu to startup the custom menu editor. Now you just need to edit your menu the way you want it and implement some event handling in your VI for the menu. For the latter there are specific examples that you can easily locate using the built in LabVIEW example finder.

I can't really help much here, but from the little I know of this, NFS may actually play a major part in it. Never had to deal with NFS myself, luckily. If you can change the server side to use a different NFS implementation, that would be at least a start. But it might be the local software that plays up. Solaris had certainly it's very special quirks in many ways. Are you locked into using NFS or accessing everything over a network share at all? Could a local storage device not work? Unfortunately Sparcs won't have an USB Bus where you could simply plugin an external harddrive.

By creating and installing your own custom menu and implementing the according menu handling in your event structure.

That's why I leave the system settings alone. If you know what to expect as numeric format when you get some numeric strings from somewhere, program in LabVIEW explicitly to that format instead of relying on the right system settings (which as you have found out can suddenly change without you knowing). When you know it is system dependent, as basically anything that comes from Microsoft is, and any programmer relying on MS libraries somehow, then do so in LabVIEW too. If you don't know, do a good guess which probably will be most times to be platform format. Last but not least when you write files that are meant for your application only, always write them in a fixed format (either always decimal point or always comma) unless the customer specifically asks otherwise. That way you can exchange data files between different installations of your application without having to worry about system settings either.