Rolf Kalbermatter

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.

The refnum is clearly disposed of and also disposes of the object. The refnum can then be reused for a different resource since its numeric value is really a 16 bit magic identifier and a 16 bit index into an array of resource pointers.

I actually leave the global system setting in LabVIEW alone and program on LabVIEW function level explicitly. If you know an instrument will send decimal point then set the scan from string and format into string to explicitly use that format instead of relaying on the user to have his system setup accordingly. Because if you work with multiple instruments and systems at the same time you will be switching the settings back and forth continuously. If you operate on user data, such as files coming from the system let it work by default with the system settings, because most applications having created that file will also use that setting. Of course if you get input from files or such from a different system all bets are off, and you will need to define a certain standard. You also can make the parser smart but that only works so far and gives sooner or later ambiguous results.

I have in the past few months steadily worked on a network library for LabVIEW with following features: - Be as close as possible to the functionality, operation and semantics of the built in LabVIEW library - Support IPv6 operation - Support SSL encryption - Support ping operation right in LabVIEW (through use of raw sockets) - and of course be better than the built in functions The included library does most of these things already but will need some more work over the next few months to fully have all these features. As such it is clearly in a preliminary state and not yet ready for released software. Please be adviced that this library will cease to operate after end of June because I expect to have new releases out there before that time. In spite of the preliminary state it does work and does do already quite a few things and it even implements the LabVIEW TCP read modes exactly as the native functions. I have included an OpenG package of the library. To install it you best use the VIPM application from JKI Software as it will take care to place everything where it should be. Due to some features I'm using it will be necessary to restart LabVIEW after installation of this library in order for the library to work properly. When installed you should see a new ESI-CIT logo in the main function palette and in there a network icon. In that network palette are all the new and exciting functions. The functions have for a large part already some online help information inside, which you can see by opening the floating help and hovering over the icons or front panel control elements. I'm working on an online help file to install along with the library but it is not yet finished. This help will also outline some of the more low level operations which at the moment may appear a bit obscure. This release is only for Windows 32 Bit systems. Sorry to the Linux and Macintosh users but porting such a library is a true pain in the a** and especially for the Macintosh I'm not yet sure how to go about it, as there are several ways to skin that cat The library will work in LabVIEW 7.1 and newer versions. readme.txt citlib_lvNetCon-0.9-1.ogp

It doesn't other than you implement it. For LabVIEW a service is just another process so to access a service you have to provide a means of interapplication communication such as TCP/IP, shared memory, even DCOM, or whatever else you can come up with. My preference is clearly TCP/IP as it is the most platform independant interapplication communication channel I know of and also has the benefit of inherent remote access ability without compilicated RPC setup and initialization. Actually you are probably misunderstanding something here. LabVIEW does not do reference counting on refnums based on VIs storing such a refnum. It couldn't really do that anyhow since a refnum is just a number that can be stored in many different formats that do not necessarily have to be refnums at some point. LabVIEW disposes a refnum as soon as the top level VI in whose hierarchy the refnum was "created" goes idle, independant how many times you stored that refnum in global VIs, global variables, locals, shift registers or whatever.

WinXP has a lot more support for USB devices on board. First it comes with drivers for most USB controller chips out there. Second it supports at least HID, COMM, Still Image, PTP, Mass Storage and Printer USB class devices out of the box. Does it come with everything? Of course not because USB allows to define new classes as any manufacturer wishes and if you register them with the USB consortium they are even official standards eventhough nobody but you may using them.

The Open VI Reference function is a very bad function to call in a tight loop. Don't do that ever as it needs to execute in the UI thread and will slow down your loop tremendously.