Rolf Kalbermatter

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.

From your post in for the DCG in the code repository I take it that you are talking here about the THThreadCreate() and friends C API. I'm afraid that there is not really a way to make the IDE aware of this thread in any way. These functions are only thin wrappers around the platform thread managment functions (CreateThread on Windows, pthread_create on Linux, etc.). As such they are used by the LabVIEW kernel to manage threads in a way that makes the actual kernel almost completely independent of the underlaying platform API, but are on such a low level that the IDE is no aware about them unless it created them themselves. Basically calling any of these LabVIEW manager functions (memory, file, thread, etc) is more or less equal to directly calling the underlaying system API directly but with the advantage that your C code doesn't have to worry about different APIs when you try to compile it for another LabVIEW target like Linux or Mac OSX. If you only want to work in Windows, calling CreateThread() directly is actually the more direct and simpler way of doing this. What is your actual issue about wanting to have the IDE be aware of your created threads?

Wow that graph certainly looks not very logical. There is absolutely nothing in the LabVIEW world which would explain the huge activity increase in 2011 and 2013. And your suspicion of spam activity probably is founded. Seems like somewhere in 2012 someone started to do some tests to launch a huge spam attack (most likely to many other foras too) in 2013 and then towards the end of the year ramped up in one last huge effort to try to make it a success and killing the "business model" definitely with that. The interesting data is likely more in the baseline where you can see that a somewhat steady number dropped to virtually 0 after the first spam attack and is nowadays just barely above 0 which would be indeed significantly lower than at the start of the graph in 2010.

It's a general tendency I have noticed on LabVIEW forums, although maybe less so on the NI forums. I also signed up at the German LabVIEW forum and while 5 or 6 years ago you had every day several new topics varying from the newbie question of how to do a simple file IO operation to the advanced topic of system architecture and interfacing to external code, nowadays it is maybe a tenth of that with most topics ranging in the more trivial category. The German forum had and has a somewhat broader target range since it was equally meant for beginners and advanced users while LAVA started by the nature of its name as a forum for somewhat more advanced topics, although I would like to think that we never really gave a newbie a bad feeling when posting here, as long as that person didn't violate just about every possible netiquet there is. The German forum may have one additional effect that may contribute to it getting less traffic and that is that English has also in Germany got the defacto standard in at least engineering. But without having any numbers to really compare I would say that the German forum and LAVA have seen similar decay in number of new posts and answers in general. And yes I have been wondering about that. Where did those people go? I feel that some went to the NI forums as they got more accessible over time but I do think that a more important aspect is that LabVIEW has gotten in many places just one of many tools to tackle software problems whereas in the past it was more often THE tool in the toolbox of many developers. That is probably a somewhat jaded view from personal experience but I certainly see it in other places too when I get there during my job. And Shaun definitely addresses another point when he mentions that LabVIEW innovation has slowly been getting to the point of stagnation in the last 5 to 10 years. That would hurt specialized forums like LAVA or a local forum like the German forum most likely a lot more than the NI forum, which catches most of the more trivial user questions of how to get something done or about perceived or real bugs. I'm not sure in how far the NI forum has been seeing a similar slow down. Personally I feel it might have been getting a little less active overal in comparison but what is more apparent is the fact that there too the general level of advanced topics has been slowing down, which would be in accordance about little to no innovations in LabVIEW. The interesting things have been discussed and brainstormed about and very little new things got added that would spur new discussions. What is posted nowadays is mostly about problems when using LabVIEW or some hardware or how to get a simple job down quickly! Is LabVIEW dead? I wouldn't feel so as I still see it used in many places but the excitement about using LabVIEW has been somewhat lost by many. It's a specialized tool to do certain things and in a way the only one in town doing it in this way, but by far not the only one you can use to do these things. In fact there have been many new and not so new possibilities about doing it (I see for instance regularly situations where people have decided to use Python for everything even the UI, which is not something I would easily consider) and the general target has been shifting too. If you want to do internet related stuff then LabVIEW is definitely not the most easy solution and also not the most powerful one. Engineering simply has been getting a lot broader in the last 10 years and while measurement and testing where you directly tinker with hardware and sensors still is quite important, there has been another big market developed that has very little to do with this and where the qualities of LabVIEW don't shine as bright or even show nasty oxidation spots. Maybe the fact that LabVIEW always was designed as a closed environment with very limited possiblities to be extended directly by 3rd parties has hurt it to the point of being forced into the niche market it always tried to protect for itself. It will be interesting to see how NI is going to attempt to fix that. The stagnation in LabVIEW development is something which supposedly happened because they focused the energy on a fundamental redesign of the LabVIEW platform, which has dragged on longer than hoped for and claimed more resources than was good for the existing LabVIEW platform.

I got that too in Chrome. Thought to wait and see again later. Still an issue, So decided to clean my cache and voila!

Even as Microsoft Certified Partner you do (did?) not have unlimited license allowance. After new versions of software are out, you are supposed to upgrade to the newest version within one year. The licenses for older versions get then invalid and with that any VM image using them, even if it is just a backup.

Hmmm, an interesting change. Looks good and pleasant to the eyes. Congrats!

Yes I'm using a somewhat enhanced OpenG Packager version for my own work. It doesn't support many things I would like but I haven't really needed them so far. But it allows simple support for selective installs. It doesn't support relocating, relinking and password protecting Vis, as that is really part of what the OpenG Application Builder was about, only that part is very much out of date as it doesn't support 8.0 and newer file types.

Having been one of the initial codevelopers of the ogp file format and spec file, I wasn't really looking at RPM good enough to say that it was based on it, but we did take inspiration from the general RPM idea and tried to come up with something that worked for LabVIEW. The format itself was in some ways more based on the old application builder configuration file than any specific package manager format. As to creating an alternative to VIPM, I would think this to be almost an effort in vain. The OpenG Commander was a good thing back in the pre LabVIEW 8 days and worked fairly well for that situation but the new project, LabVIEW libraries and classes and various other file formats introduced with LabVIEW 8.0 and later really are a very different breed in many ways. Also VIPM really is a combination of the Open G Commander, Open G Package Builder and the Open G Application Builder, but then severly enhanced to handle the new file types too, which is a very complicated process and requires quite a few undocumented VI server methods, and some of them changed between versions, so it's hard to support more than two or three LabVIEW versions at all. As to saying that NI doesn't provide a good source code control solution is kind of going into the wrong direction. I haven't seen many software developer tools coming with source code control from the same manufacturer that actually work good in any way. Microsoft couldn't pull that trick and there is nothing that makes me believe that NI has even nearly as many resources available than MS. There are ways to use source code control with LabVIEW. Not ideal ones but there aren't any ideal solutions as far as I'm concerned even outside of LabVIEW. LabVIEW has a few extra hurt points as some of its files are big nasty binary blobs, that none of the source code control tools can handle efficiently but all of the modern ones can at least handle them. The more modern XML based files while being text based have a problem in that just about every source code control system will not be able to handle them consistently as simple text based merging is not enough. And context based merging is still in its infancy and doesn't even work well for other XML based files with fully known schema. But to turn around and requiring the LabVIEW files to be in a format that can be easily merged automatically is also not really realistic.

I'm sorry but I'm not likely to work on this anytime soon. We use MS Office in the office, so OpenOffice is not a logical choice for me to work on, and our projects would usually require to work with MS Office too, if they require any office automation integration.

Well, then your NetBEUI to IP address resolution is not working properly. Your previous comment about going directly to the network path, I was actually more refering to entirely alternative protocols such as WebDAV or (S)FTP.

Except going directly the network path? Not really! There might be some obscure registry setting which influences the timeout, but in my experience the default timeouts for accessing remote file paths through Windows file API are rather to long than to small. I don't like to wait for 1 minute to finally get an error that a file path is not currently accessible since the network or remote server is down. Identifying that registry setting is going to be difficult and made extra complicated as it may vary depending on your current setup and logged in credentials. That file API is layered on top of the kernel API which is layered on top of the NetBEUI protocol, which then makes use of Winsock, which then calls into the socket driver and from there in the network card driver. NetBEUI is/was a nice invention back in the days of DOS and got carried over since, but it did not have a rich control interface for things like timeouts, etc. It simply goes and sits for whatever time the developer found reasonable. The Windows file API does only support timeouts on its own level through asynchronous API calls, which is cumbersome and in most cases serves no extra purpose other than freeing up the current thread to do something else while the file API waits for the underlaying resource to become available. LabVIEW does not use the asynchronous file API since it doesn't give LabVIEW anything extra and even if it did, this is entirly seperate from possible timeouts in lower level file system drivers like NetBEUI. Generally I would say your Windows domain setup is somewhat flaky, so that the NetBEUI driver can't always verify the access rights of the current user for the desired network resource in time. This setup used to be fairly straightforward in Win NT 4 times but got tightened up a lot since, so that it is very easy to make errors when configuring domain users and access rights, and this errors often only occur occasionally, depending on network load, actual login mode and various other temporary conditions.

I believe that it should be possible to do, but likely will require to crosscompile the entire NI Linux RT kernel sources in order to configure them for a standard PC rather than the NI specific hardware. Other than that it should be less critical about needing specific hardware (virtualization) than the Pharlap system, since the Linux kernel was and still largely is originally developed on and for the PC. It's been more than 15 years that I compiled my own Linux kernels from scratch and installed them onto a second boot partition so it will be taking some time for sure to figure out all the details. If I ever happen to get some spare time, I'm probably going to try that, but don't hold your breath for it.

What about the LVCompare.exe tool that can be used to automate source code control clients to know how to deal with LabVIEW files more friendly? http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/configlvcomp_thirdparty/ That should do most of the things required here and has various options to ignore certain classes of changes in the comparison.

It's a first step towards 3.0 compatibility but by far not enough. 3.0 changed a lot of things. As to running LabPython 4.0 with Python 2.7 I guess that thanks to the runtime dynamic linking, it may work fine as long as you don't hit code paths that depend on the symbols that changed in 2.7. And that is in fact something that makes me wonder if the dynamic linking is a good idea . Different Visual Studio versions might certainly have some influence. I'm not sure anymore if there are any resources that are shared across the Python-LabPython boundary but that would be totally problematic for sure if the Visual Studio and therefore the C runtime library versions differ.

Native Excel files are using a proprietary format, either binary (pre Office 2012 or so) or compressed XML. Both formats are not something that is easily read in LabVIEW although there is a Toolkit which can read and write XLS files directly. Another approach is to use ActiveX to interface to Excel and access the files like that. There are several libraries out there which wrap the ActiveX nodes to make it easier, since the ActiveX object hierarchy of MS Offce software is rather involved and not trivial to understand. But in order for this to work you need to have Excel installed on the computer you use such a library. For the rest it really would help to give more info as was asked multiple times in this thread already. It's rather frustrating to see multiple requests for extra info and then seeing that you keep providing further information in piece meal fashion and if you keep doing that the readyness to help you further will quickly diminish also for future requests you may have. If the files are however in tab or comma separated text format then the Read Spreadsheet file function will work perfectly.

You should probably not attempt to set the absolute path to the Python27.dll when it was installed in System32 (or more likely SysWow64 as in my case when installing the Python 2.7.11 version from Python.org). In that case just specifying Python27.dll alone should be safer. Also note that the LabPython 4.0.something package that gets installed from VIPM is not compatible with Python 2.7. They changed various things in 2.7 in preparation for 3.x including removing some symbols from the DLL and then the LabPython initialization fails because it can't link to the expected symbols. I have prepared some fixes to the current LabPython code that conditionally links at initialization time to the correct symbols but haven't found time to properly build a new VIPM package for this.

The problem is that when Python is started it determines its home path from a number of possible values and then determines the sys.path value from that. This is then used to find modules that you "import" in a script. It does among other things check values like the PYTHONPATH and PYTHONHOME environment variable, registry entries and finally if that all doesn't lead anywhere the current executables directory. From there it tries to find the Lib directory inside the determined home path. However I just installed Python 2.7.11 from the Python site on my machine and I don't see any environment variable nor registry entry for Python. That forces the Python DLL to rely on two remaining parameters, all of which don't help either. First the location of the Python DLL which has been moved from the Python directory to the Windows system directory in the past, so no way for Python to find out where it got installed, and then as last resort the executable directory, which is the LabVIEW installation directory; no joy to find the Python lib directory from there either. For the Python executable this last one is which saves the butt when running from within the Python console, but leaves any application that embeds the Python DLL in the cold. Possible Workarounds: 1) append the relevant Lib path to the sys.path variable before your import statement (something like sys.path.append("C:\Python27\Lib") 2) Define PYTHONPATH=C:\Python27\Lib;<other possible module directories> or PYTHONHOME=C:\Python27 environment variable 3) Create a registry key HKLM\Software\Python\PythonCore\<version>\PythonPath\<name>" with the value of the Lib path 4) NOT RECOMMENDED: the default sys.path Python uses when everything else fails is a list of relative paths which would resolve to the so called Current Working Directory. This can be set with a call to the SetCurrentDirectory() Win32 API. Setting this to the Python Home path would theoretically work, except that this path is also modified by various other Windows functions, most noticably the File Dialog box, so using it as a runtime reference is a very brittle solutions. Seems like there is actually infrastructure in the Python DLL to work with that, but that the standard installer forgets to set any of the possible values to help this infrastructure to do its work. There is no good way to remedy that from within LabPython itself since it shouldn't inherently know about Python installation specific details.