Rolf Kalbermatter

I think he was refering to using Google. Wouldn't know what the extra keyword "site:lavag.org" would otherwise help in the search on this site. If you want to limit your google search to that extend is of course another question but generally you can always extend it later if you find you get to few hits.

While ActiveX is already a legacy technology according to MS, they won't just chop it off like that from any of their products without a really strong reason. Depreciation will happen eventually, first by prominent remarks in the documentation, then by removing the documentation slowly from all Microsoft servers but removing it from the applications itself? No way! Windows still supports many technologies from its 16 bit protected mode times, such as DDE, just to name one and while MS says: Don't use it! it's still part of the shell interface to all normal Windows applications.

I don't think you need to write the data twice each time. You need to shift the data once whenever you wrap around the end of the buffer on write, but that is all. The one drawback I see with this is that it could make the write operation pretty erratic in execution time and therefore unsuited to be called directly in a time critical or realtime loop.

Or you make your tool configurable with an address and port number for each one. Also notice that if you ever should have more than one version of LabVIEW on a computer you better give them each their own port in the configuration.

The address is whatever IP address the computer has on which the IDE runs, or localhost if it is on the same computer. The port number is configurable in the LabVIEW Options, and you need to enable the TCP/IP interface to VI Server in there too, in order for it to work (but if you ever have used VIPM to install some software package into LabVIEW, that is probably already enabled).

Have you checked out the BLT Toolkit? It's already done and readily avialable on the LabVIEW Tools Network.

You need to provide the Application Open function with an address and port number to connect to, otherwise it will simply connect to its own instance, which is why you only see the VIs in your executable.

Well I misunderstood you there then! But for Linux you have inotify() or the older dnotify() to do something similar than with FindFirstChangeNotification() under Windows. inotify() is present since around kernel 2.6.13 and glibc 2.4 and working from glibc 2.5, so nowadays there should be no reason to have to use the inferior dnotify() functionality.

See here: http://www.mail-archive.com/sqlite-users@mailinglists.sqlite.org/msg53058.html It comes from the fact that SQLLite is a file based database, not a server based one. The SQL Lite shared library is the entire SQL Lite database engine, but as DLL it gets loaded into each process seperately and does not share any state from another SQL Lite shared library engine in another process. It does use file range locking (when enabled in the build) in order to maintain some kind of consistency even if two processes happen to modify the data concurrently. And it apparently does at least under Windows (when enabled in the build) use file notifications to get informed about changes from other processes but in order to detect what has changed it then has to read in all the data again and update its internal management information so I'm not sure why it would work under Windows like Shaun claims. Basically the fact that SQL Lite is a file based database more or less makes what you want pretty impossible. The solution most people have come up with is to add an extra table which stores records about changes to tables and then query that regularly, possible with a file change notification callback mechanisme to avoid to much polling.

Either way to make this useful you would want to have this translated into a user event and that will require the creation of an external shared library which can install that callback which then is translated into a user event through the LabVIEW PostLVUserEvent() C manager API function. As the current interface goes to great lengths to avoid having to create an intermediate shared library this is not a trivial addition to the library but a very significant change, especially since every supported platform will require the creation of its own shared library (Windows 32 and 64 bit, Linux 32 and 64 bit, and MacOSX 32 and 64 bit makes already 6 different shared libraries not to mention the extra at least 4 cRIO flavours). And I might be misreading the documentation for that function but it does not call the callback for a specific table but for any row update, insert or delete in any rowid table for the current database connection. But not for tables without rowid.

Not simply like that. It was part of project work so copyright is an issue. And it is definitely a to big project to tackle as a one man show. One complication with OpenCV is that the newer API is C++ based so you will not get around to creating an intermediate shared library either. And unfortunately the IMAQ control does not seem to work on non Windows platforms eventhough it is mostly a built in control in LabVIEW itself and not provided by the IMAQ Vision software, so there is the need to add an additional element to handle efficient display of images in some form of external window and that is thanks to different windows managers not always straight forward.

Actually even Vision is an option under Linux through OpenCV, although far from an out of the box experience as with NI IMAQ Vision. I've been using OpenCV on Windows in several proof of concept apps and been dabbling with the Linux side of that a little. It definitely looks like W10 is not going to be used much for any real industrial application platform. Maybe the embedded variant has some more customization options, but that has its own bucket of complications. Microsoft really doesn't know what they really want to do. This one is interesting but based on a platfom that is autoupdating forcefully it seems more useful to go directly to Linux for industrial applications.

Well yes and he is still right! Nobody forced you to write a V4L interface library for LabVIEW! And besides, think about how much C code you would have written if you had to write the UI part for all this too! But in your tracing of the C macros I actually fail to see how the bitness would get into play.

My first advice besides debbugging as poiinted out by Yair, would be to try to communicate from the same LabVIEW version first. While the LabVIEW flattened format is designed to stay compatible across versions, variants are a very special beast that have a much more complicated data structure than most other LabVIEW datatypes. There is a serious chance that flattened Variants are not always binary compatible between LabVIEW versions.

I would agree with ensegre. Macros with parameters may look like functions but they are not!. It's more evidenced by the uppercase name and the prepended underscore. It's sure not a guarantee, but it is common practice to name constants and constant macros with uppercase letters, and function names with all lowercase (or in Windows with the CamelCase names). While it may seem a bad idea to make the constant different depending on the bitness this is probably made necessary by the fact that the structures can contain pointers which changes the size of the structure and the _IOWR() macro indicates actually a device driver ioctl() value and device drivers have always the bitness of the kernel even if the application which calls them may have a different bitness (and the driver is required to recognize that and translate any pointers accordingly to its 64 bit flat memory model.

https://sourceforge.net/projects/labpython/files/labpython/1.2/ should be compatible back to LabVIEW 6.1 or so. But it will not work with the newer Python releases at all, Python 2.6 32 bit is probably the highest version that has any chances to work.

Well with the DSC functions you can create the OPC UA Items. Reading an ASCII formatted spreadsheet file is trivial and really should not pose any problems after reading the resources that JKSH has posted. Implementing the logic about grouping items according to their folder that is not really a LabVIEW problem but simply a classical programming problem about sorting/grouping items in a list. As such I'm not inclined to do the programming work for you. It's not fundamentally difficult but it is a lot of nitty gritty work to do for me just as well as for you and it's your problem to solve.

I can't really give you more help here than what I added in my last post. LabVIEW out of the box only supports querying and updating OPC items, configuration is entirely manual. If you want some programmatic configuration capabilities you need to either get the LabVIEW DSC toolkit or another 3rd party OPC UA interface library.

Crosspost http://www.labviewforum.de/Thread-OPC-UA-Labview-Reading-items-and-properties-from-excel-sheet-or-text-file and http://forums.ni.com/t5/LabVIEW/OPC-UA-Labview-Reading-items-and-properties-from-excel-sheet-or/td-p/3295449 As to your specific question, standard LabVIEW only supports querying and updating OPC UA items programmatically. Configuration of them is manual. There is the LabVIEW DSC Toolkit which also supports some limited programmatic configuration of OPC UA items, but not as extensive as it supports the old OPC items.

Hmm, using an asynchronous protocol like OPC UA for things like phase shift calculation is already your first problem. OPC UA at least in single update mode (it may have also streaming modes but I don't think they are exposed in LabVIEW at all if they even exist) has absolutely no synchronisation between the sender and receiver nor between the two channels. It's a publish-subscriber system where the sender publishes the data to be read by the receiver when it suits him. So the actual relation between the two signals and between sender and receiver in terms of timing is at best uncertain. That makes phase shift analysis between two signals about as reliable as measuring voltage with your finger tips! You should really look at a different protocol where the two channels are transmitted synchronously (that means over a network almost always together in the same data stream and in streaming mode so that the time information is inherent in the data stream. Otherwise you just see some random phase shifts that have more to do with the reliability of your network and the OPC UA stack than anything in your actual signals unless your signal has a frequency of not more than a few mHz, then the accuracy of the network and protocol are probably enough to allow you at least some estimation of phase shift between the signals.

This function most likely was added at some point for TestStand to call LabVIEW test adapters. But I'm pretty sure they use different functionality in newer versions. And using this has a high change of breaking at some point. NI controlling both the caller as well as the callee and not having documented that function in any way, can easily decide to change something about this interface. They won't do it just to pester you, as the work to make these changes is significant, but if there is a technical or business reason to do it, they will and will not even acknowledge your complaints of breaking this functionality. I've been investigating the possibilities of calling VIs directly from a DLL myself in the past and came across this and some other functionality but simply didn't feel it was worth spending to much time on it if it was not somehow publically acknowledged by NI. It would have been a very handy thing to use in LuaVIEW as it would make callbacks into LabVIEW code so much easier for the user than what it does now. And it would most likely allow multiple turnarounds between Lua and LabvIEW code which LuaVIEW currently disallows to even attempt because of the stack frame handling which gets completely out of control if we would try to allow that.

I really don't know the details. A VI reference is simply a somewhat complex index into a list of VI data structures. This VI data structure is a huge C struct that contains all kinds of data elements including pointers to pointers to pointers to pointers of various data. Some of this is the diagram heap, the front panel heap, the data space heap, and the compiled code heap. And this structure changes with every LabVIEW version significantly since there is no external code ever directly accessing it. Interfacing anything in this structure directly is a complete nogo as it will be totally incompatible with every new LabVIEW version, even service releases and potentially bug fix releases. And the actual machine code is not just a function pointer segment that you can jump too with the parameters on the stack, instead the code directly refers to it's parameters through VI internal structures from the conpane and all. Setting that up correctly on your own is definitely a way into total crazyness.

Can you be more clear? Which function? RTSetCleanupProc() only indirectly has a reference to the current top level VI, this function doesn't take a VI reference in any way, It determines that internally.

But the three callbacks all have one argument. It's the InstanceDataPtr. This is a pointer to a pointer sized variable that is stored by LabVIEW for each CLN callsite. LabVIEW provides you that storage, what you store in there is up to you. It could be an integer that allows you to identify the resource associated to this callsite or a ponter to a structure as simple or complicated as you wish. The reserve function is called when the diagram is iniitialized. the unreserve before the diagram is unloaded and the abort when the hierarchy that this CLN callsite is located in is aborted. And yes you can configure the CLN to pass exactly this InstanceDataPtr also to the actiual function. It won't show up as a parameter on the CLN icon but LabVIEW will pass exactly this pointer to the function. So your reserve function allocates some datapointer to identify the callsite, the actual function stores whatever it wants into that pointer and the abort function checks if there is anything in there that needs to be aborted, canceled or whatever. The unreserve function needs to deallocate any resources that were allocated in either the reserve or run function and not yet cleared by the abort function. Sounds pretty much like what the undocumented RTSetCleanupProc() function does: enum { /* cleanup modes (when to call cleanup proc) */ kCleanRemove, kCleanExit, /* only when LabVIEW exits */ kCleanOnIdle, /* whenever active vi hierarchy goes idle */ kCleanAfterReset, /* whenever active vi goes idle after a reset */ }; typedef int32 (_FUNCC *CleanupProcPtr)(uintptr_t resource); TH_REENTRANT int32 _FUNCC RTSetCleanupProc(CleanupProcPtr proc, uintptr_t resource, int32 mode); Basically this function can be used to register a pointer sized integer with according cleanup function pointer, that will be called with the integer parameter whenever the event that is used as mode happens. This is supposedly the functionality that is used by most LabVIEW refnums. They all use the kCleanOnIdle mode. Don't forget to call this function again with the same function pointer and pointer sized integer and the kCleanRemove mode whenever you are finished with this resource so that the cleanup entry gets removed from the internal list. And yes these entries seem to be stored in a linear list so it might be a good idea not to flood that list with unneccessary resource entries in order to keep your LabVIEW system responsive. If you find this fact disturbing or worse, please forget that you heard about this whole funcitonality.

There is one publically available interface that could allow something like this although not very well documented. It is the callback configuration in the Call Library Interface Node. Basically every Call Library Node can register "callbacks" that are called when the diagram on which the Call Library Node is placed is initialized and deinitialized. And all these callbacks have a pointer parameter that can also be configured to be passed to the actual Call Library function too. It's not straightforward but a lot easier than trying to figure out code signatures to call into internal functions that might vary from LabVIEW version to version.