Rolf Kalbermatter

They own Digilent, MCC (and with it Data Translation) and a few other companies that all work in that segment. So yes it would make sense to combine that all into a new independent company and make it self supporting. So far they didn't seem to do much with it. It almost feels like it was mostly about buying up competition than any specific long term strategy to build something out of it.

LabVIEW never has been a money maker for NI directly. They were able to develop LabVIEW because of what they earned with their hardware sales. And LabVIEW was used to drive those hardware sales. A very successful model that drove others like HP Vee and such out of the market in the not very long term. Maybe HP/Agilent also was simply already to big for that market segment that they could possibly target with a product like this. The entire T&M component market isn't that huge. For HP it was what they had been starting with, but the big money was earned (and sometimes biggly lost) already in other areas. T&M was good for a steady revenue, but nothing that would stand out on the yearly shareholders report. It was unsexy for non-technicals and rather boring. That was one of the big reasons to separate HP into multiple companies. An attempt to create smaller entities that target a specific market segment and could be fine tuned in the sales and marketing efforts to the needs of that market. About 10 years ago NI reached the size where they started to feel the limitations of the T&M component market themselves. There simply was not a big enough market left that they could capture, to continue their standard double digits yearly sales grow for much longer. Some analysts were hired to look into this and their recommendations were pretty clear. Don't try to be the wholesale everything for all little parts manufacturer in T&M, but concentrate on specific areas where big corporations with huge production lines invest their test and measurement money. Their choice fell on semiconductor testing and more recently the EV market. It has a huge potential and rather than selling ten-thousends of DAQ boxes to hundreds of integrators, they now sell and deliver hundreds of fully assembled turnkey testers to those corporate users and earn with each of them more than they could ever earn with several 1000 DAQ boxes. What used to be NI's core business is nowadays a side line, at best a means to deliver some parts for those testers. But more and more a burden that costs a lot of money in comparison to the revenue it could even under ideal conditions generate. If you can understand this you also can guess where NI is heading. They won't die and their shares will likely not falter. But what they will be has little to do with what they used to be. If LabVIEW still has a place in this I do not know. Personally I think it would be better if it was under the parapluie of a completely separate entity than the new NI but I also have my doubts that that would have long term surviving chances. Earning enough money with a development environments itself is a feat that almost nobody has successfully managed for a longer period. But the sometimes heard request to Open Source LabVIEW has also not a lot of chances. It would likely cause a few people to take a peek at it and then quickly loose interest, since its code base is simply to complex. And there is also the problem that the current LabVIEW source code never could be open sourced as is. There are so many patent encumbered parts in it and 3rd party license dependencies, that nobody would be legally allowed to distribute even a single build of it without first hiring an entire law firm to settle those issues. While NI owns the rights for them or acquired a license to use them, many of these licenses do not give NI the right to simply let others use them as they wish. So open sourcing LabVIEW would be a fairly big investment in time and effort before it could be done. And who is willing to foot that bill?

Are you referring to scripting? It still is there and is called Transaction Start and End.

No I haven't but according to this page there are a number of possibilities. - ODBC driver This should be possible to be accessed with the LabVIEW Database Connectivity Toolkit with very little problems. - SQL API This is a REST API. As such it could be used with the HTTP Client VIs in LabVIEW. However it will require some work of your own to write wrapper functions around the desired API endpoints that take data and format it into JSON to send as HTTP request and then decode the response from JSON into actual data.

You need to translate them. There may be a service in the PLC that lets you translate names to addresses but I have no experience with Omron PLCs. For Beckhoff PLCs it is possible to retrieve a list of variables that enumerate all variables with their name and list the actual register address where they are stored. Lacking that you need to refer to the W227E12 FINS document and locate your type of PLC in there. There is a Memory Area Designation for each model series that tells you how the CIO, TR, G, A, AR, CNT etc registers map to memory addresses. And then from your ladder logic you have to determine what specific register address a variable may have, and then translate that to a linear memory address and then use the FINS "MEMORY_AREA_READ" and "FINS_MEMORY_AREA_WRITE" commands to get that information. The library on the github site is a bit strange as it packs all the TCP/IP handling into a LV 2 style global. That makes the whole a bit complicated to use and won't allow for instance two parallel connections to two different PLCs. It would have been a lot better to actually create LabVIEW classes that keep the connection related information in the class wire. That would allow to implement a layered approach where you have a basic class that implements the actual FINS protocol (pretty much what this library is) and also provides empty overwrite templates for actually writing and reading to registers by their type and offset and then implement for each PLC type a small child class that translates the register type into an actual linear memory address for that PLC type.

This project may be interesting. It talks directly the Omron proprietary FINS protocol: https://github.com/jmor2000/LV-OMRON-FINS No OPC, no special Ethernet/IP function block or whatever needed on the Omron PLC. While the Omron FINS protocol is proprietary it is actually openly documented by Omron: https://www.myomron.com/downloads/1.Manuals/Networks/W227E12_FINS_Commands_Reference_Manual.pdf

Technically it is all passed around by pointer, which is synonymous to by reference. Logically that makes no difference whatsoever as it all happens under the hood. Data going into a subVI through the connector into a control is consumed by that subVI and considered to be private to the VI. If LabVIEW needs that data somewhere else, it will make a copy, but it has optimizing measures in place that may schedule different functions consuming the same data in a way that they can not stomp on each others data. Data coming through an indicator out of a subVI is from that point owned by the caller and the VI better doesn't try to change it after the fact. For LabVIEW VIs that is not a possibility at all as LabVIEW takes care of that. For data returned from external code through a Call Library Node, it is a grave violation of the LabVIEW memory management contract to try to modify the data in the background once the Call Library Node call has returned control to the diagram. LabVIEW is a managed environment just like .Net but has different management rules. As far as LabVIEW diagrams are concerned there is virtually no way to violate those rules since the dataflow determines everything. If you interface to external code then you could violate that management contract in the external code but doing so is equivalent to placing a bomb in your PC! 💣

You were to fast. I typed a wrong URL 😀

If you want to get some more background information (including pretty much useless historical details nowadays) you may also want to read through these blog posts: https://blog.kalbermatter.nl

I used to put a lot of trust into what was on the Farnell site in respect to the product description. But since Corona hit or maybe even a bit earlier, the information on the Farnell site for products has gone downhill. Not only doesn't the text always match the actual product but also the available datasheets for a product listing are either only slightly related and sometimes outright wrong. I used to report such inconsistencies but refuse to be their unpaid website reviewer!

If you want to build a product, even a free download, around the C Generator, think again! It is discontinued and will not come back ever and almost certainly doesn't work in the latest LabVIEW version without trouble. It can anyhow not officially get installed beyond LabVIEW 2017. The resulting code is, let's say "interesting", but trying to understand it is another matter. And if you end up trying to solve a problem with it, you are very likely simply ending up with at least one more problem than before, rather than one less! 😀

According to this page, the part number 777849-35 is the single seat LabVIEW Pharlap ETS deployment license. Never mind the strange currency in those pics which seems to be Indian Rupias. And the online download page is here, when you select the Debug/Deploy option. The download page is less clear about what exactly it is, and the order number shown is rather 777845-35, but I'm pretty sure it is really the Pharlap ETS license and the information on the Farnell site seems therefore bogus. Considering that NI discontinued support of Pharlap ETS for all options already in the latest LabVIEW version, it's amazing that you still can buy it.

NI Linux RT is the NI version of the Linux kernel and as such is of course GNU licensed. You can grab the sources and compile it yourself and install it on whatever hardware you want! BUT!!!!! That is just the Linux kernel. The LabVIEW runtime engine, NI-VISA, NI-4882, NI-PAL, NI-DAQmx, NI-IMAQ, NI-RIO and many more NI-somethings all are fully and completely copyrighted by NI and you do not have the right to copy them around as you wish. While drivers like NI-VISA and NI-DAQmx are generally also available for standard desktop Linux systems and from there can be installed on your own x86 based (embedded) hardware, this is an entirely different beast for the LabVIEW real-time runtime engine and all its dependencies. For this you would need to get an explicit license from NI or risk to get their lawyers chase your butt. Also the ARM compiled NI-drivers are also NOT part of a standard driver installer but only come with the LabVIEW realtime runtime installer or the Community Edition target firmware Installer for Raspberry Pi and Beaglebone Black. The LabVIEW realtime runtime is ONLY licensed to you according to the respective license that comes with those two. For the LabVIEW realtime runtime installer, that is explicitly only licensed to run on NI hardware and the Community Edition comes with the explicit non-commercial use only restriction. So until NI decides to sell an actual NI Linux realtime runtime license as they did for the NI Pharlap runtime license you are not only skating on thin ice by using those components on your own hardware but fully and truly illegal. However the support burdon for such a license is most likely the main reason they haven't done anything more than saying that they are monitoring the market and will decide when they feel it is useful. That was 8 years ago their standard response, and with the current state of affairs, chances that they will release something like that are actually quite a bit smaller than back then.

Basically the point I was trying to make also in previous topics about CINs. 😀

As daddreamer pointed out, quite a bit of those functions are actually documented and always have been. The first multiplatform version of LabVIEW shipped with about 15 cm of printed manuals and reached at its top probably 25 cm. One of the many manuals was called the Code Interface Reference Manual. And while the name might have seemed to only be useful in Code Interface Nodes, those functions were always also available in shared libraries too since LabVIEW added official support for calling them. The information in that manual is for most of it also contained in daddreamers link, without the CIN specifics, which are nowadays useless and really have no advantage to shared libraries since about LabVIEW 7.1 but many disadvantages (and the 64-bit versions of LabVIEW do not support them anymore. Yes I'm aware that someone tried to hack them anyways into LabVIEW 64-bit and was partially successful. But it's an exercise in vain as it really has no advantages whatsoever to shared libraries). This is the Code Interface Reference Manual from around LabVIEW 3.1 (Release September 1994). It is 16mm thick and there were about 6 or 7 other manuals like that, some of them more than double as thick than this one. Lot's and lots of trees being cut down for all those LabVIEW manuals! It's for the most part the same as is also in daddreamers link, but there the CIN part is removed and few extra functions are documented that were added since then Some of the undocumented functions could be useful sometimes but being undocumented, it is a bit of a problem as they could change at anytime or completely disappear, which has happened to many of them over the course of LabVIEW development. Some were exported in the past for the compiler to be able to create code to access them directly but are useless to be called from your own external code as you lack access to internal data that needs to be passed to those functions to be useful. Some are still there as a placeholder but simply return a notImplemented error as they were moved to other parts of LabVIEW and only the export remained to make external code that depended on them in the past not load up broken but instead return a runtime error. CINs that didn't load really could throw LabVIEW into a fit. There are various additional managers to the documented Memory, File and Support manager functions in that manual but most are not really helpful. Things I have experimented with in that past and I would have liked to have more official access too, were the MagicCookie handler (all LabVIEW refnums are under the hood MagicCookies), UserDataSession (a more functional wrapper around MagicCookies), (which with the help of something called ObjectManager allows to add special crafted shared libraries through a descriptive text file, directly into the LabVIEW refnum system and access the shared library functions through property and method nodes), Thread, Mutex and Event manager (which basically offers a common interface to the underlying platform threads, mutexes and events), and it even has a Window manager, which abstracts the underlying OS windows into its own window API. But that Window manager is for modern requirements with multi monitor virtual desktops a bit arcane and one of the reasons that LabVIEW isn't that great on such setups. But it is very involved and hairy in some parts to make the various windowing systems such as Mac Quickdraw, Mac Cocoa, Windows GDI and Unix XWindows all map into the same common API. That makes any attempt to change something on one platform a really taunting exercise as it has a great chance to break one of the other platforms. There are also things like a Text manager (a VERY arcane attempt to abstract fonts and text handling into a set of functions), a Dialog manager, which allows to create dialogs in C code that use a LabVIEW VI front panel as resource for the user facing GUI but the entire handling is done in a compiled function from C(++). A Resource manager handles all the binary file formats in LabVIEW that are very much modeled around the old Macintosh resource file format. These are all things that were mostly present in LabVIEW 3 or 4 already, with the exception of the Thread, Mutex and Event manager, which was added in LabVIEW 5 when LabVIEW got true OS supported multithreading, and the UserDataRefnums which were around LabVIEW 7. I have very little knowledge about the interna of things that were added after around LabVIEW 7.1, as that was when I stopped to really dig into the LabVIEW internals. There is an extensive LVVariant interface that gets also exported since around LabVIEW 8.0 and which would allow to also work with Variants in external code, if it was documented. There was some header file downloadable in the past as part of the CUDA toolkit that contained some of these declarations and with it it would be possible to do some experimentation, but without real documentation it is rather cumbersome. Now before you start and scream that NI has kept all these nice cookies from you, consider that most users even struggle with the documented functions already and that are the more simple APIs. Much of what I described above would require several centimeters of printed manuals for each of them! It would also mean that these APIs are absolutely carved in stone and never ever can be changed again, which is something NI has kept to in all this time, unless there was an obvious bug in one of the documented functions. The undocumented functions allowed a much more lenient handling when something needed to be changed. The only people going to scream and show up with a rocket launcher because something broke, were either NI internal people or someone bold enough to hack around undocumented functions, where the LabVIEW developers simply could say: Bad luck! You were not supposed to play with those rusty nails!

I do, and I would argue that on the NI forums it is mostly on technical merits. > Hi, my labview program doesn't work, what should I do to make it work? Sorry pal, but with that much information I feel terribly overwhelmed! 😀 Besides it is spelled LabVIEW! > My VI doesn't work. I attached it. How can I make it work? (appended a grainy image of a section of a diagram that spans at least half a dozen screens) You didn't attach a VI but an image of a small part of the diagram of your VI, and you see, it is said that an image says more than 1000 words and sometimes that is true. But in the case of LabVIEW, the actual VI itself says even more than 100 images! It can be looked at and invisible attributes of objects can be examined and yes it can even be debugged, which an image pretty much can't other than for the most glaring and obvious bugs. Besides it would help to make a VI that can fit on one screen, and preferably not your 8k ultrawide super duper gaming monitor that nobody else can afford.

It's not just LAVA. All of the LabVIEW related forums are very low traffic compared to lets say 5 to 10 years ago. Sure it is more spread around nowaday, with NI forum, LAVA, German LabVIEW forum, Info-LabVIEW, Reddit, Stackoverflow and YouTobe all having some LabVIEW participation. The German forum is since 2 or 3 years practically dead, with maybe one or two posts per month, Info-LabVIEW has only a few diehards who still post questions there with maybe one question a month, LAVA is fairly active but much less than several years ago and on the NI forum, participation is also definitely lower and in other forums than for LabVIEW practically 0. Even in the LabVIEW forum there is considerably less traffic and participation of Blue Eagles is VERY thin. Leaves Reddit, Stackoverflow and YouTube, which I almost never follow. But from what I have seen there, the quality is often very limited both for questions and the answers that are given. YouTube videos are sometimes quite helpful, but often just a rehash of some tutorial that are available elsewhere or even outright wrong. So I would say it definitely has slowed down and while you could argue that everything has already been asked before somewhere and therefore there are very little new questions that can be posted, I don't quite buy that as only possible reason. And the fact that NI support very seldom participates even in their own forum is quite a telling thing too.

If you are not using this code anywhere then you are fine here. I thought you may use it in some production code and I would find it in that case not a very responsible choice to swipe it under the rug with the reasoning that it just works anhow.

Actually that is wrong. It will still work on 32-bit LabVIEW. The 32-bit Windows Winsock is documented to use 32-bit SOCKET values, LabVIEW will pass a 32-bit value to the DLL even if the LabVIEW wire is 64-bit as you configured it as pointer sized variable in the Call Library Node. This means all is peachy in both 32-bit and 64-bit LabVIEW no matter what Windows decides to do underneath. With your current setup the 64-bit value returned by socket(..) will be downconverted to 32-bit and transported as such through all VIs and then upconverted each time to a 64-bit value when calling a WinSock library function (if that parameter is correctly configured as pointer sized integer. If not only the lower 32-bit for that parameter are guaranteed to be initialized and the upper 32-bit may contain garbage, which may or may not be a problem). That may go fine as long as the upper 32-bits aren't used but it may also go wrong. If you change it to be a LabVIEW 64-bit integer everywhere in LabVIEW itself and configure those parameters everywhere as pointer sized integer, it will always go right, until Windows 128-bit comes out of course, but I have a suspicion that by that time, we both will not program in LabVIEW anymore, and LabVIEW may be an anecdotal remark in the history of programming languages that existed somewhere in a long ago past.

It's common industry standard. So why should NI be an exception? Wanting to download Windows XP for whatever strange reason? Visual Studio 2005 or 2008, just to be a bit obnoxious? It all can be done, but no IT company is trying to make that simple without some special paid support contract. Why? One reason is that people who use those versions will eventually often need some kind of support too and giving even the most simple of support such as license activation or some installation troubles is significantly more effort to do for anything but the last version.

What I mean here is that SOCKET is defined to be an UINT_PTR. This means on 64-bit Windows it is a 64-bit entity even nowadays. The fact that the upper 32-bit may or may not be used internally is an implementation detail that we as API users should NOT rely on. So while it MAY work to only transport 32-bit around in the LabVIEW library, this may be something that only works by change on your machine, or may sometime in the future fail generally because of some under the hood design change. While I agree that you could argue that such future changes are not your current problem and you are justified to charge in the future for that modification if it starts to fail, it is the fact that it may even nowadays fail. We don't know what a SOCKET is and even by looking at its numeric value and finding that it never goes higher than a few 1000, indicating that it is really more like an index into some internal table, there is no guarantee for that. It could very well be a pointer that happens to usually be mapped to a below 4GB address but may suddenly also be allocated above that limit and then your 32-bit handling fails. Factually, treating the SOCKET variable always as 32-bit value at even a single point in your program is a bug as it does not match the published API documentation. The fact that it may not crash or fail for you, is no argument to leave that bug in the code. It's the same thing generally with people who dabble with the Call Library Node: "Look mom, it doesn't crash anymore!!", wrap it up and declare victory is the totally wrong mindset here. Once it doesn't always crash immediately anymore, the real hard work only starts, as not every memory corruption immediately will crash your process, but instead may crash way down the timeline after you have written and added several dozen more modules to your program and then the bug hunting is VERY cumbersome as you have no idea where to start and may instinctively suspect the last changes you made (well I usually have an idea, if there is a DLL involved anywhere it has about a 95% chance to be the culprit even if it never crashed before 😀). The only exception to that rule was for me in the past if it was a LabVIEW binding that came with NI drivers. Those are usually very stable and almost never the cause of a crash. But any other DLL binding, self developed or from any 3rd party is a prime suspect in those cases.

I think you should. The upper 32-bits of the SOCKET on 64-bit platforms may not be used nowadays but there is no guarantee that it won't be used in the future, for instance as you get Windows 12 or Windows Jubilee or something, that will only be available as 64-bit OS anyways. Someone at Microsoft may decide to stick something into those unused 32-bits of the SOCKET or may decide that it should be directly a pointer anyways. Then this library won't work if you didn't consequently change the socket handle to be a 64-bit integer in LabVIEW and all Call Library Nodes to use a pointer sized integer for these parameters. As to byte swapping, it can be an annoyance but I find that sort of byte twiddling actually entertaining. 😀

I can't help you with this. We have created many cRIO and some sbRIO systems in LabVIEW and while we see the supply chain disruption too that makes getting the correct systems getting shipped in time a real problem, we have not yet considered redesigning any of them without LabVIEW. If we would go that route I do not expect to reuse much of the existing LabVIEW code in any way. The design documents are likely the only thing that will be really helpful, which is one reason to actually do them and not just trust into "LabVIEW code is self documenting". It seldom is when you look at it a year or more later unless it is very trivial code and for FPGA code it really never is trivial but there are many involved code segments used typically. Even the realtime part would need to be rebuild with something else as interfacing LabVIEW to 3rd-party FPGA designs is not easy. You would at least need to replace the entire cRIO shared library with something of your own that interfaces to whatever FPGA architecture you are using.

Smart thinking, I was overthinking this with the conditional compile structure. Just create a 64-bit array and declare the parameter as pointer sized integer array and LabVIEW will happily do the conversion automatically on 32-bit platform. Just one caveat although it is of no significance nowadays anymore. This trick of treating the fd_set structure simply as an array of integers only works on Little Endian with 8-byte compiler alignment. On Big Endian this would go wrong as the count stays a 32-bit integer no matter what and the low significant 32-bit of the first 64-bit integer would go in the wrong place. But the only Big Endian platform that LabVIEW still had until recently was the VxWorks real-time targets and their Berkeley socket implementation is mostly Unix like although with some interesting deviations, that usually would not really matter if you just compile a program from C sources with the correct headers but definitely could go very bad when trying to interface with a LabVIEW VI to it that has no notation of their header files but simply requires you to play header parser yourself.

That library was reworked by me in 2008, before LabVIEW had any 64-bit version. Unfortunately, SOCKET in Windows is an UINT_PTR which means that it is a 32-bit integer on 32-bit LabVIEW and 64-bit integer on 64-bit LabVIEW. But you can NOT port this over to Linux as is. There the file-descriptor used for all socket functions is an explicit int, so always a 32-bit value! This is because the Berkeley socket library is originally developed for Unix and build around the generic socket concept in Unix which traditionally uses int file descriptors. When Microsoft took the Berkeley socket library and adapted it for Windows as WinSock library, it was already very revolutionary to have this as a fully 32-bit code library, Windows itself was still mainly a selector based 16-bit environment. And Microsoft likes to use handles, which are opaque pointers and happened to be 32-bit integers too back then. The library as posted on the NI forum does NOT work in 64-bit Windows, and that is not just because of the 64-bit SOCKET handle itself but also because of the fd_set data structure which is defined as follows: typedef struct fd_set { u_int fd_count; /* how many are SET? */ SOCKET fd_array[FD_SETSIZE]; /* an array of SOCKETs */ } fd_set; Now on 32-bit LabVIEW there is nothing strange here. The fd_array with SOCKET handles begins at offset 4, so the LabVIEW array of 2 * 32-bit integers works perfectly fine. The first array element corresponds to fd_count and the second element to the first element in the fd_array and if fd_count doesn't contain more than 1 as value it does not matter that the fd_array doesn't contain all 64 elements that this structure is declared for. On 64-bit the SOCKET is a 64-bit integer and is naturally aligned on an 8 byte boundary in that structure. So there is a dummy 32-bit filler element between fd_count and fd_array. And the first SOCKET should be a 64-bit integer. Solution to make this work on 64-bit LabVIEW, besides changing the SOCKET handle parameter for all functions to be a pointer sized integer, is to use a conditional compile structure. For the 32-bit case use an array of 32-bit integers as fd_set just as is used now, for the 64-bit case you need to use an array of 64-bit integers. The rest remains the same. You even can use an array of 2 * 64-bit integers, just the same as for the 32-bit case with an array of 32-bit integers. Since we run on a Little Endian machine under Windows, the lower significant 32-bits of the first 64-bit element happen to match the location in memory where the fd_count is expected, the extra 4 filler bytes are overwritten by the higher significant 32-bits of the first 64-bit array element which is not a problem. They are really DON'T CARE. Your observation that this weird error can happen if the fd_set structure is not correctly initialized was spot on. But not because it is not really correctly initialized in the VI (it is) but because the array of 32-bit values has a different layout than what the 64-bit Winsock library expects.