Rolf Kalbermatter

We don't know your ion gauge, nor what it does and how it functions. It could be that the instrument driver for it simply returns its own errors as LabVIEW errors so that the actual numeric value means something completely different than what one would expect from LabVIEW functions. It can also try to read some file somewhere. All guess work if you don't provide a LOT MORE information about your program, hardware and source code. You usually don't go to a car shop and tell the mechanic that your car doesn't work and if he could tell you what the problem is without taking the car with you so he can have an actual look at it, do you? You know more about your software than anyone here does, so you need to tell us as much as possible about it in order to allow us to help you! As to where to post, I notified a moderator and they moved the thread into the General area, where you should have posted it in the first place.

I didn't mean external hardware but what is build into the system. A memory module, a built in HD, the system board. Together with a less than perfect thermal design that can mean that the hardware gets hot enough that some less than perfect hardware gets into soft errors.

Definitely not an Instrument Driver thing. The only thing besides faulty hardware that can still create BSODs in Windows are faulty device drivers. They run in the kernel space of Windows and there is really nothing that Windows can do to prevent a kernel driver from corrupting its memory. That is why 64 Bit Windows (and the latest versions of MacOS X) by default only allow to load signed drivers. In order to get a driver signed the manufacturer has to submit it to some test review process and that tries to make sure the driver conforms to certain test scenarios in order to make sure it will work flawlessly in all but the very most extreme exceptions. Today a BSOD is a pretty reliable sign that you have some hardware problem in your system, such as a bad harddisk, PCI bridge, or memory that can cause temporary dropouts.

Error 6 is a permission error. That can have many reasons and without knowing which function gives you this error there is really not much we can do to help you. Most likely it is a file permission error. So maybe you login with a different user than before or your system administrator changed the access rights for your user account. By the way: You posted in the wrong forum too. This seems to have nothing to do with OpenG functionality at all, so should have been posted in one of the more general forums.

One possibility is to use the Call Chain and reference the latest element in the resulting array. That is the top level VI of the current call chain, so might not be the top level of the entire application (when you use VI Server->Run VI or Call Asynchronous, but should be close enough). Otherwise there should be an "App->Parent Window for Dialogs" property but last time I checked that always returned a 0 handle, which for most Windows APIs requiring a parent handle would mean that it is system modal as the 0 HWND is treated as a shortcut for the Desktop window, which is the parent of any other window on the desktop.

That's pretty harsh! The source code is on sourceforge and there is nobody preventing other people from accessing it and attempt to port it to 64 Bit LabVIEW. It won't be easy but given enough determination it is certainly doable.

It might be possible but it is far from just a recompilation of the code. The code was written at a time where nobody was thinking about 64 bit CPUs and no standards existed how one should prepare for that eventualiity. Also it is possible that the script interface in LabVIEW has been cleansed of support for older API standards for the 64 bit version. LabPython uses the first version of that API, but if the 64 bit version of LabVIEW doesn't support that anymore, then the new version documentation would need to be gotten from NI. This is not an official public API.

As Shaun already elaborated, the issue is always about the LabVIEW bitness, not the underlaying OS (well, you can't run LabVIEW 64 bit on 32 bit Windows but that is beyond the point here ).

Yes. See his comment to add 32 bit support later on.

The problem is certainly not endianess. LabVIEW uses internally whatever endianess is the prefered one for the platform. Endianess only comes into the picture when you flatten/unflatten (and typecast is a special case of flatten/unflatten) data into differently sized values. This is why you need to byte swap here. Your issue about seemingly random data is most likely alignment. LabVIEW on x86 always packs data as tight as possible. Visual C uses a default alignment of 8 bytes. You can change that with pack() pragmas though.

Well, I'm not sure what your hourly rate is. But a LabVIEW upgrade is almost certainly cheaper than trying to recreate that effort for yourself, if you intend to use the result in anything that is even remotely commercial.

You wouldn't need all that swapping if you had placed the natural sized element in that cluster, an int64 for 64 bit LabVIEW and an int32 for 32 bit LabVIEW. For the 0 elements in your cluster it doesn't matter anyhow. Now you have a dialog with a title and a single string in it and it already looks complicated. Next step is to make it actually usefull by filling in the right data in all the other structure elements!

of course that won't work! That sqlite3 **ppDb parameter is a pointer to a pointer. The inner pointer is really a pointer to a structure that is used by sqlite to maintain information and state for a database, but you as caller of that API should not be concerned about that contents. It's enough to treat that pointer as a pointer sized integer that is passed to other sqlite APIs. However in order for the function to be able to return that pointer it has to be passed as reference, hence the pointer to pointer. Change that parameter to be a pointer sized integer, Passed by reference (as pointer) and things look a lot different. However, seeing you struggle with such basic details, it might be a good idea to checkout this here on this site. Someone else did already all the hard work of figuring out how to call the sqlite API in LabVIEW.

I would tag it übernasty. Really, it's an API that I find even nasty to use from C directly. Very likely there is. With all it's own complexeties such as correct .Net version that needs to be installed and instantiated by LabVIEW on startup. But the interfacing is made pretty easy since .Net provides a standard to describe the API sufficiently enough for LabVIEW to do the nasty interface conversion automatically.

Problem is that this structure is pretty wieldy, uses Unicode strings throughout and many bitness sensitive data elements. Basically, each LP<something> and H<something> in there is a pointer sized element, meaning a 32 bit integer on LabVIEW 32 bit and 64 bit integer on LabVIEW 64 bit. Same for the P<something> and <datatype> *<elementname> things. and yes they have to be treated as integer on LabVIEW diagram level since LabVIEW doesn't have other datatypes on its diagram level that directly correspond to these C pointers. Not to talk about the unions! So you end up with at least two totally different LabVIEW clusters to use for the two different platforms (and no don't tell me you are sure to only use this on one specific platform, you won't! ) Trying to do this on LabVEW diagram niveau basically means that you not only have to figure out how to use all those different structure elements properly (a pretty demanding task already) but also play C compiler too, by translating between LabVIEW datatypes and their C counterparts properly. You just carved out for you a pretty in depth crash course in low level C compiler details. IMHO that doesn't weight up against a little unhappyiness that LabVIEW dialogs don't look exactly like some hyped defacto Microsoft user interface standard that keeps changing with every new Windows version, and that I personally find changing to the worse with almost every version.

What are you trying to do? This is a pretty hairy structure to interface to from the LabVIEW diagram. I definitely think the only reasonable approach is to write a wrapper DLL that translates from proper LabVIEW datatypes to the according elements in this structure. A major work but the only maintainable solution! So is there anything you hope to achieve with this that you couldn't do with native LabVIEW elements?

You definitely need to show your DLL function prototype and the diagram that calls it, preferably in VI form and not just an image. What you expect us here to do is showing us a picture of your car and asking why its motor doesn't run!

I understand your concerns, but reality is that any multiplattform widget library (be it wxWidget, QT, Java, LabVIEW or whatever else you can come up with) is always going to be limited with whatever is the least common denominator for all supported platforms. Anything that doesn't exist on even one single platform natively has to be either left away or simulated in usually very involved and complicated ways, that make the code difficult to understand and maintain. And the LabVIEW window manager does contain quite a few such hacks to make things like subwindows, Z ordering, menus and common message handling at least somewhat uniform to the upper layers of LabVIEW. Hacky enough at least to make opening the low level APIs to this manager to other users a pretty nasty business. I'm sure there are other marketing driven reasons too, that Apple didn't include a cfWindow interface to NSWindow into its CoreFoundation libraries, but even if they did, they certainly wouldn't have tried to map that to the WinAPI as they did with most other CoreFoundation libraries.

And that is exactly what LabVIEW does. It's Window manager component is a somewhat hairy code piece dealing with the very platform specific issues and trying to merge highly diverging paradigmas into one common interface. It makes part of that functionality available through VI server, and a little more through an undocumented C interface which lacks a few fundamental accessors to make it useful for use outside of LabVIEWs internal needs. Yes "one" could! And what you describe is mostly how it would need to be done. But are you volunteering? Be prepared to deal with highly diverging paradigmas of what a window means on the different platforms and how it is managed by the OS and/or your application! And many hours of solitude in an ivory tower with lots of coffeine, torn out hairs and swearing when dealing with threading issues like the LabVIEW root loop and other platform specific limitations. I don't see the benefit of that exercise and won't go there! What for? For MDI applications? Sorry but I find MDI one of the worst implementation choices for almost every application out there.

"/usr/lib" should be in the standard search path for libraries, and if the library was properly installed with ldconfig (which I suppose should be done automatically by the OPKG script) then LabVIEW should be able to find it. Note that on Linux platforms LabVIEW will automatically try to prepend "lib" to the library name if it can't find the library with its wildcard name. So even "sqlite3.*" should work. However I'm not entirely sure about if that also happens when you explicitedly wire the library path to the Call Library Node. But I can guarantee you that it is done for library names directly entered in the Call Library Node configuration.

Ahh licensing! Well, I'm also in the last stage of finalizing a license solution for all LabVIEW platforms. Yes, including all possible NI RT targets!

Good luck with that! On Linux the native handle is supposedly the XWindows Window datatype. On Mac I would guess (don't have looked at it but entirely based on assumptions) that for the 32 Bit version it is the Carbon WindowPtr and for 64 Bit version it is an NSWindow pointer (and yes this seems to require Objective C, there doesn't seem to be a CoreFoundation C API to this for 64 Bit). So, you have at least 4 ENTIRELY different datatypes for the native window handle, with according ENTIRELY different APIs to deal with! And no, the Call Library Node function can not access Objective C APIs, for the same reason it can't access C++ APIs. There is no publically accepted standard for the ABI of OOP compiled object code. I guess the Objective C interface could be sort of regarded as standard on the Mac at least, since anyone doing it otherwise than what the included GNU C toolchain in X code does is going to outcast himself. For C++ there exists unfortunately not such an inofficial standard.

That's actually covered in that document. Any child references of the front panel are "static" references. When the VI server was pretty new (around LabVIEW 5.1) those were in fact dynamic references that had to always be explicitedly closed. However in a later version of LabVIEW that was changed for performance reasons. If you attempt to close such a reference the Close Reference node is in fact simply a NoOp. This is documented and some people like to go to great lengths to make sure to always know exactly which references need to be closed and which not, in order to not use the Close Reference node unneccessarily but my personal opinion is that this is a pretty useless case of spending your time and energy and simply always using the Close Reference node anyways is the most quick and simple solution. One way to reliably detect if a returned refnum is static or dynamic is to place the node that produces the refnum into a loop that executes at least twice and typecast the refnum into an int32. If the numeric value stays the same then it is a static refnum, otherwise it is dynamic and needs to be closed explicitedly in order to avoid unneccessary resource hogging of the system.

As if that would be any better! i have seen very bizarre behaviour with customers both when using McAfee and Norton and have a few pretty bad experiences myself with McAfee. Bad enough that we did not renew the license. On one side they like to be notoriously present in anything you do, on the other hand their UI allows little to no configuration options anymore. LabVIEW tends to do all kind of things when starting up, which opens many files all over the place. Virus scanners like Norton and McAfee like to intercept that every time and not in a way that is performance wise to be ignored. Works fine if only a few files are involved but runs completely awry with a high number of files being queried during a programmatic operation. Unfortunately it is not something that seems to be consistent from machine to machine. These virus scanners cause trouble on some machines and the same version seems to work fine on others and it is almost impossible to analyze why. But removing them also makes such problems go away, so go figure.

One reason why EtherCAT slave support isn't trivial is that you need to license it from the EtherCAT consortium. EtherCAT masters are pretty trivial to do with standard network interfaces and a little low level programming but EtherCAT slave interfaces require special circuitry in the Ethernet hardware to work properly. One way to fairly easily incorporate EtherCAT slave functionality into a device is to buy the specific EtherCAT silicon chips from Beckhoff and others which also include the license to use that standard. However those chips are designed to be used in devices, not controllers so there is no trivial way of having them be used as generic Ethernet interfaces. That makes it pretty hard to support EtherCAT slave functionaility on a controller device that might also need general Ethernet connectivity, unless you add a specific EtherCAT slave port in addition to the generic Ethernet interface, which is a pretty high additional cost for something that is seldom used by the majority of the users of such PC type controllers.