Rolf Kalbermatter

Well that's the problem of using layered software. Standard socket operations are normally synchronous and don't have a timeout parameter themselves. In order to program asynchronously, one has to first set the socket into O_NONBLOCK and then use select() or poll() before attempting to do a read() or write(). And the timeout for most synchronous socket operations is an option that can be changed for each socket through the setsockopt() call. VI Server might use internally asynchronous sockets but it is designed as a synchonous interface to the user. The reason is obviously ease of use, since asynchonous interfaces are usually pretty hard to use and debug. And unfortunately nobody thought ever about adding a possibility to add a timeout property to the VI server refnum class. But that's understandable since the VI server refnum is not generally a network connection, it just can be routed over a TCP or ActiveX connection, but just as much be a LabVIEW process internal protocol layer. A timeout property would only be meaningful to the TCP protocol layer but wouldn't apply to the other two classes. It's the classical problem of abstraction where you can't and don't want to expose all the lower level details to the higher level interfaces, especially when they are not universal for all the lower level implementations.

Not sure about OPC UA details but generally server to server doesn't make much sense and simply makes setup of the system more complex. Possibly OPC UA allows for some hybrid configuration where a server can be configured to relay data from another server as some sort of gateway between differently secured network segments, but other than that I see no real benefit in complicating the server configuration by adding the possibility to let a server relay data from another server.

The issue is a little more complicated actually since NI Linux RT isn't a single platform but really two (x64 and ARM). There is no easy solution to provide a virtualized environment for testing on the ARM platform (but with the myRIO you do have a fairly accessible platform for testing). So far we have these variations of platforms for LabVIEW RT: x86 Pharlap ETS PPC vxWorks 6.1 (LV 8.2.1) and vxWorks 6.3 (>= LV 8.5) ARM NI-Linux RT x64 NI-Linux RT For all but the Pharlap ETS system virtual machines for testing are only theoretically feasable for the NI-Linux RT for x64 platform. All the others already fail because of a very different CPU architecture and adding Bochs or something similar to the virtualization effort is definitely creating an even bigger problem. Still remains the issue that without an NI sanctioned way of creating an NI-Linux RT (x64) image, it's not only legally but also technically pretty impossible to create a fully functional LabVIEW RT target for virtual machine execution. There are simply to many runtime libraries that need to be copied to the right locations, that are not part of NI Linux RT itself but additional components with specific NI license restrictions. There are also possibilities for some of the x86/x64 systems to run Windows Embedded but for testing purposes of libraries they are really the same as a standard Windows systems if you don't access very obscure features.

I can't speak for others, but for me the NI Linux RT virtualized hardware system would be mostly for testing and debugging LabVIEW software on one of the x86 based cRIO targets without having to always be connected to the actual hardware target. Yes it doesn't allow for full hardware access such as DAQmx, RIO etc. but it would allow some easy testing of the general RT application and in my case especially shared libraries on these platforms.

It's not that easy. You do not pay for a runtime license of the Linux kernel. That is open source and NI provides all the sources to recreate it, if you wish. But NI Linux RT while a full OS is simply that! No LabVIEW runtime, NI-VISA runtime, NI-488.2 runtime, NI-DAQmx runtime, NI-RIO, NI-this and NI-that. And for these things, and especially the LabVIEW runtime, NI is free to define whatever license conditions they like and they decided that running these on non-NI hardware generally will require a paid license from them. You are free to build your own NI Linux RT OS for whatever hardware you like, but you are not free to put any of the NI software even in runtime form on it without a license from NI. And no, just because you can redistribute a LabVIEW executable including the LabVIEW runtime on a desktop system without additional runtime licenses does not mean that you have the right to grab a LabVIEW runtime from an NI Linux embedded target and copy it to your own hardware , even if it would be technically possible, which for most targets is not easily possible even if they use the same CPU architecture. NI Pharlap isn't that different really. They probably have a royality free source code license from Pharlap for this (which would cost A LOT of money, which of course has to be incurred somehow and probably comes with a similar expensive yearly maintenance contract for them). The license cost for the NI Pharlap system on your own hardware is for the most part the same as for the NI Linux software. It's for the LabVIEW runtime and all the other necessary software drivers, not so much for the Pharlap OS. NI makes quite a bit of money with their realtime platforms and they want to protect that somehow. And being the copyright owner of all the NI developed software drivers and LabVIEW, they have every right to do so in pretty much every way they find ok. That you and me would rather have it different isn't really a valid argument against that.

I haven't really looked into this and I'm not aware of such a specific guide. My guess is you have to setup a linux cross compile setup on your PC, then download the NI Linux RT source code and go through the configuration settings of the linux compilation, selecting everything that would make sense for your (virtual) target hardware. That gives you in the end a hopefully working Linux RT kernel that is compatible to NI Linux RT. Now, NI Linux RT is of course a nice thing but completely useless as a target for LabVIEW RT without also the LabVIEW runtime engine, NI-VISA, NI-DAQmx, NI-half a hundred other software libraries and drivers. And here you start to bite in the dust. You can't just recreate them for your target system and you are not allowed to copy them over from another LabVIEW RT system without expressed consent from NI and in the case of the LabVIEW runtime engine an actual license payment too!

In my experience almost all forum searches suck badly in comparison to the standard set by Google. So I would say: Disable it!!

NI's stance on such things (and basically any company in the US and most other places) is: We do not comment on internal developments, plans for development or lack thereof or whatever, unless we are at a stage with it that it is ready for prime time. It may sound dissatisfactory for us mere users, but reality is that there are simply to many legal and other implications in our modern system, that speaking before the fact can have far reaching consequences. Basically every employee knows that commenting on unreleased products or technologies without approval from higher management might be the signature under a resigning letter that has no possibility for reappeal. So you can hope for a reaction from someone from NI about this, but unless they have it ready to be announced at coming NI week you can keep waiting until the hell freezes over. Even then it is not likely that they will react here.

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.