Jump to content

Dear NI


Neil Pate

Recommended Posts

19 hours ago, Neil Pate said:

Take the hard work done in NXG and make VIs into a non-binary format human readable so that we can diff and merge with our choice of SCC tools

I see a lot of people wanting this, but why? We code graphically after all. The way to make sense of the underlying code to a G-programmer is to present it as G-code, not text...

Ideally we had a SCC-system made specifically for graphical code, but I do not expect that to become a reality (unless someone made it on top of an existing one perhaps). Personally I live relatively comfortably with the solutions we can set up already, but would prefer to see it better integrated into LabVIEW and/or have out of the box solutions on how to get started with various major SCC alternatives. 

If the VIs were humanly readable it might make it easier to create more powerful alternatives to VI Scripting though, and to generate code at run-time in built applications...That is something else.

  • Like 1
Link to post
42 minutes ago, Mads said:

I see a lot of people wanting this, but why? We code graphically after all. The way to make sense of the underlying code to a G-programmer is to present it as G-code, not text...

Ideally we had a SCC-system made specifically for graphical code, but I do not expect that to become a reality (unless someone made it on top of an existing one perhaps). Personally I live relatively comfortably with the solutions we can set up already, but would prefer to see it better integrated into LabVIEW and/or have out of the box solutions on how to get started with various major SCC alternatives. 

If the VIs were humanly readable it might make it easier to create more powerful alternatives to VI Scripting though, and to generate code at run-time in built applications...That is something else.

It is presented as G code...when loaded into LabVIEW. All that is being proposed is for the on-disk representation to be in a format that normal SCC can deal with rather than a proprietary binary format that prevents us from incremental differencing.

Projects et. al. have already gone this route. The suggestion is to extend it to the VI's themselves. We know that VI's *can* be represented in forms such as XML from some of the under-the-hood tools we have seen. The current state of affairs in how SCC's deal with LabVIEW source is the equivalent of using SCC for C/C++ object code, and the NI graphical solution is far too manually intensive.

As for the rest of Santa's list. Most of it is "gibs free stuff":ph34r:

Edited by ShaunR
Link to post

Free is maybe pushing it. Zero technical support without a SSP would be an appropriate model associated with open source. Of course this wouldn't prevent a vibrant community support (independent from NI) from existing, but this is not what the big industrial companies using LV would go for. They would remain NI's proverbial cash cows. 

I think the misunderstanding on the corporate side of why open source is beneficial for code safety and reproducibility is understandable, as I can witness the same ambivalence if not resistance in academia.

As for NXG and webUI (or whatever they call it now), as discussed elsewhere, it looks like NI doesn't have the resources to bring the vision (whatever it was originally) to fruition, and their recent decision  to abandon it will probably lead (or has already led) to morale cratering and talent effusion, so I wouldn't hold my breath...

One thing I'd add to the list is this: stop the yearly versioning breaking backward compatibility. This is frankly moronic and the clear and only reason why this exists is NI pricing scheme. Adopt the scheme suggested in the first paragraph and this can go right away.

Edited by X___
  • Like 2
Link to post
On 12/25/2020 at 7:30 PM, Neil Pate said:

Remove support for Linux and Mac and start to prune this cross compatibility from the codebase. I know this is going to get me flamed for eternity from 0.1 % of the users. (You pretty much made this decision for NXG already). Windows 10 is a great OS and has won the war here.

I actually don't care enough for LV to get triggered by the first sentence. But the last one... 😡

  • Thanks 1
Link to post

Couldn't agree more.

I also believe NI really need to push LabVIEW more aggressively to the maker community. This is a group of people who adores things that are "free", "open", "lite" and today, LabVIEW simply doesn't make the cut. Of course the coolness factor will still be an issue (a night/dark mode could probably help?) but surely there must be a way to position LabVIEW as a great tool to help creative geniuses to focus less on grit and more on, well, actually creating stuff.

I work in the aerospace-defense-industry. With hardware. But we are fewer and fewer who does. The majority of the engineers now are software engineers who either work purely with software or come from that background. To explain to them why NI's offering makes sense is extremely difficult.

Of course, for now, what we do is relatively complicated and closely tied to the performance of the hardware. So using NI’s locked-in eco system saves us time and money. But NI’s pyramid is crumbling from the base. At other companies I’ve seen well-made LabVIEW application been ripped out and replaced with “anything” written in Python. Of course it didn’t work any better (quite the opposite), but it was Python and not LabVIEW. And that single argument was strong enough.

Edited by codcoder
Link to post

I think there is a compromise here that would help with contending with Python, if it's not too late - make Linux repositories available for older LabVIEW versions.

I remember vaguely that there was one for 8.6. So if there were, say, repositories of versions older than 5 years; it would be a route for people to get into LabVIEW and enable makers, students, and the terminally curious to code in LabVIEW without impacting the current sales.

But be careful what you wish for. The probable solution to the demands for free stuff will ultimately end up as LabVIEW-as-a-service.

Link to post

The problem with the argument about better mergeability if LabVIEW would use a text based file format is that XML and really any format that can represent more complex data structures, can not easily be merged with current tools. It doesn't even fully work for normal text based languages as the merge tool can NOT determine what to do when two code modifications occurred at the same or immediately adjacent  line location in a text file. You end up with conflicts that have to be resolved manually. While that is doable although not fully painless for normal text based languages, XML and similar formats pose an additional challenge since a change in one element can actually cause changes in multiple line locations, often separated by many text lines. As soon as two different changes are somehow not totally independent in line location, you can't merge just based on line information. And in the worst case a single change can basically mean a modification right in the beginning of the file and one at the end. With such a change any other change is potentially very problematic to merge. And just doing the standard conflict resolution for text files as it is done now, with including both sections and letting the user manually decide which to use, would basically just create a double as big file, which would be pretty useless to try to manually merge.

So while converting LabVIEW binary files to XML or similar sounds like a good idea, it won't solve the problem of merging in source code control really. In a way the current situation is easier: You know it can't be done automatically so are forced to plan accordingly! XML may in that respect seem to many to promise something that could not be delivered anyways in most merge situations. To do any meaningful merging for anything but the most trivial modifications in XML format, one would have to create a diff/merge tool that fully understands XML and to make matters worse, it should also be aware of the actual schema used in the XML file. Even then creating an XML format from that merge result would be only partly helpful, one would really need an interactive merge visualizer that presents the XML data structure to the user directly in a suitable graphical form such as a tree view and lets him select the relevant modification when there are any logical conflicts.

As to creating external tools for dealing with LabVIEW files without the need to script things in LabVIEW itself, the idea sounds good, but I doubt it will be used a lot. Maybe a translation tool for different languages but many such things are rather runtime features than edit time features.

About throwing away LabVIEW for non-Windows platforms: That is hardly an argument to even start to try to remain relevant in comparison to things like Python or in a far far future from now maybe .Net. Python runs on pretty much every hardware you can imagine that has a C compiler available, from low end 8-bit microprocessors to extreme high end system.

There are also literally exclusive points in that list.

* Stop adding new features to LabVIEW for several years

This directly contradicts several other items in that list.

Edited by Rolf Kalbermatter
  • Like 1
Link to post
On 12/27/2020 at 7:58 AM, Mefistotelis said:

I actually don't care enough for LV to get triggered by the first sentence. But the last one... 😡

I agree, I have garnered great disdain for Winblows over the years as far as the negative impacts to our testers from updates mandated by IT departments, obsolescence, the pain to install unsigned drivers, just to name a few.  I would hate to see NI stop support for Linux as it has been growing in popularity and getting more user friendly.

Linux is a great and stable platform, though not for the faint of heart.  It takes more effort and time to build the same thing you could do in shorter time with Windows.  However, If LabVIEW were open source and free, you could theoretically build systems for just the cost of time and hardware.  I've been wishing over the years that they would support LabVIEW on Debian based systems as well.

I've created two Linux/LabVIEW based setups in the past and never had the issues I've run into with Windows.  Yes, it took more time and effort, but as far as I know - the one(s) I created (circa 2004-5) have been working reliably without issue or have even required any troubleshooting or support since their release.  One is running Mandrake and the other an early version of Fedora.

Edited by Bryan
Link to post
5 hours ago, Bryan said:

I agree, I have garnered great disdain for Winblows over the years as far as the negative impacts to our testers from updates mandated by IT departments, obsolescence, the pain to install unsigned drivers, just to name a few.  I would hate to see NI stop support for Linux as it has been growing in popularity and getting more user friendly.

Linux is a great and stable platform, though not for the faint of heart.  It takes more effort and time to build the same thing you could do in shorter time with Windows.  However, If LabVIEW were open source and free, you could theoretically build systems for just the cost of time and hardware.  I've been wishing over the years that they would support LabVIEW on Debian based systems as well.

I've created two Linux/LabVIEW based setups in the past and never had the issues I've run into with Windows.  Yes, it took more time and effort, but as far as I know - the one(s) I created (circa 2004-5) have been working reliably without issue or have even required any troubleshooting or support since their release.  One is running Mandrake and the other an early version of Fedora.

Maybe 2021 will be the year of Linux on the desktop, but given that this has been predicted every year since about 2003 I would not hold my breath.

LabVIEW will never be open source. It would not make sense, nobody outside of NI would be able to maintain it. LabVIEW is not the Linux kernel which is of huge interest to millions of others. The area of the intersection on the Venn diagram of skilled enthusiastic LabVIEW developers, ultra-skilled C++ developers, and those with enough spare time is approximately zero. The full complement of engineers at NI can barely make any progress into the CAR list, what hope is there for anyone else?

Edited by Neil Pate
  • Like 1
Link to post

It could be open source and still be maintained by NI, as long as they have a way to generate revenue. There is also great potential in the NXG platform, which - as far as I know - is written in C#. Even if LabVIEW is not of interest to millions of people, keep in mind that most open source projects only receive contributions from a small portion of their users.

The Linux kernel is probably not a good comparison, because it is orders of magnitudes more complex than LabVIEW. Nevertheless, Linux "only" received contributions from approx. 16k developers between 2005 and 2017 - 2017 Linux Kernel Report Highlights Developers’ Roles and Accelerating Pace of Change - Linux Foundation. Compare that to relatively young projects as Visual Studio Code (~1400 contributors), or the .NET Platform (~650 contributors). These are projects with millions of users, but (relatively speaking) few contributors.

2 hours ago, Neil Pate said:

The full complement of engineers at NI can barely make any progress into the CAR list, what hope is there for anyone else?

It depends. Companies might be willing to pay developers to fix issues. Enthusiasts might just dive into the code and open a pull-request with their solution. Some items might not be of particular importance to anyone, so they are just forgotten.

Link to post
1 hour ago, Neil Pate said:

Maybe 2021 will be the year of Linux on the desktop, but given that this has been predicted every year since about 2003 I would not hold my breath.

It never will be until they resolve their distribution issues which they simply do not even acknowledge. Even Linus Torvalds refuses to use other distro's because of that.

What Windows did was to move common user space features into the kernel. The Linux community refuses to do that for ideological reasons. The net result is that application developers can't rely on many standard features out-of-the-box, from distro-to-distro, therefore fragmenting application developers across multiple distro's and effectively tieing them to specific distro's with certain addons. Those addons also have to be installed by the end-user who's level of expertise is assumed to be very high.

  • Like 1
Link to post
21 hours ago, ShaunR said:

application developers can't rely on many standard features out-of-the-box, from distro-to-distro, therefore fragmenting application developers across multiple distro's

There are two APIs to graphical systems: X-window and Wayland.

X-window contains compatibility layer for Wayland, Wayland contains compatibility layer for X-window. And most libraries which help creating GUIs allow to compile the same user code for both.

 

Microsoft won by donating Windows to schools, and providing courses for teachers. This paid out over years, making Windows a template by which all OSes are judged.

Now, at least is EU, there is a movement to require open-source OS in all public institutions. This should, over years, remove some of that bias.

 

Link to post
20 hours ago, Mefistotelis said:

There are two APIs to graphical systems: X-window and Wayland.

X-window contains compatibility layer for Wayland, Wayland contains compatibility layer for X-window. And most libraries which help creating GUIs allow to compile the same user code for both.

Microsoft won by donating Windows to schools, and providing courses for teachers. This paid out over years, making Windows a template by which all OSes are judged.

Now, at least is EU, there is a movement to require open-source OS in all public institutions. This should, over years, remove some of that bias.

XWindows is not the main problem, although admittedly not the most easy API to tackle UI drawing. I think QT would be a lot easier but there you have licensing issues if you are not a truly open source project. But XWindows as an API is pretty standardized and has very few of the problems Shaun alluded too. But XWindows is just a basic UI API. Once you want to tackle things that are more user related you end up with a myriad of different desktop management standards that are all fundamentally different and while there were some attempts to standardize things they are usually not much more than recommendations that different projects adhere to in very different ways.

Also another problem in the Linux world are various system interfaces that sometimes change on an eye wink and also can greatly vary between Linux distributions. And if they don't  change entire subsystems just because they can, it is quite common to make binary incompatible API changes that require often specific version of libraries and aren't upwards compatible at all.

So if you want to install library XY you end up needing library Z, V, A and T all in specific versions except that library ZV needs some of these in different versions and if your project depends both on XY and ZV you are screwed. That each of those Linux distributions uses their own packaging system doesn't help this at all either. It's not just the repositories that vary but also the format, dependency tracking and all that.

If you want to develop an application like LabVIEW that should support all major Linux distributions you end up spending countless hours of debugging and code tweaking to work around all these kind of trouble only to have to do the whole work again 6 months from now. 

Link to post
23 hours ago, Rolf Kalbermatter said:

So if you want to install library XY you end up needing library Z, V, A and T all in specific versions except that library ZV needs some of these in different versions and if your project depends both on XY and ZV you are screwed.

This is the problem that WinSxS solves, as you probably know.

The various Linux packaging systems aren't much help here either. There is, of course, a binary version control under Linux that utilises symlinks-usually the latest version is pointed to though. That is where we end up trying to find if the version is on the machine at all and then creating special links to force an application to use a particular binary version with various symlink switches to define the depth of linking. It's hit-and-miss at best whether it works and you can end up with it seeming to work on the dev machine but not on the customers as the symlink tree of dependencies fails. That resolution needs to be handled much better before I re-instate support for the ECL under Linux again.

And like Rolf says, that has to be done again in 6 (I argue weeks, not months) for the release of a new version in order for the application to continue working when there have been zero changes to the application code.

Edited by ShaunR
Link to post
On 1/2/2021 at 8:51 PM, ShaunR said:

This is the problem that WinSxS solves, as you probably know.

Yes, except that without WinSxS you had one problem, with WinSxS you end up having several more problems! 😀 

While maintaining binary compatibility across library versions requires some real discipline, abandoning that and trying to solve it with something like WinSxS is simply getting you further down the rabbit hole.

Link to post

In reply to Neil's opening, here's my 2 cents about what I suggest NI should do :

From what I read in this thread

It seems that NI's NXG dev team was made of people who didn't have enough love for LV-CG- or enough experience using LV-CG for real world applications.

Well now that NI's plan is to move forward with LabVIEW, my suggestion is that they make every NXG dev spend 50% of their time contributing on LabVIEW related open source project.

There's a lot of great project on GitHub, Bitbucket, GitLab, etc. started by passionate LabVIEW users who have the greatness to share their toolkits, frameworks, API, etc.

They have limited resources in most cases, so now that NI has a full team of developers with no real purpose and and not enough understanding of what makes LV-CG great, then let's make them contribute to growing the LV-CG eco-system.

 

edit :

if you agree >> https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-NXG-dev-team-contribute-to-LV-related-open-source-projects/idi-p/4110996

Edited by Antoine Chalons
Link to post
3 hours ago, Antoine Chalons said:

In reply to Neil's opening, here's my 2 cents about what I suggest NI should do :

From what I read in this thread

It seems that NI's NXG dev team was made of people who didn't have enough love for LV-CG- or enough experience using LV-CG for real world applications.

Well now that NI's plan is to move forward with LabVIEW, my suggestion is that they make every NXG dev spend 50% of their time contributing on LabVIEW related open source project.

There's a lot of great project on GitHub, Bitbucket, GitLab, etc. started by passionate LabVIEW users who have the greatness to share their toolkits, frameworks, API, etc.

They have limited resources in most cases, so now that NI has a full team of developers with no real purpose and and not enough understanding of what makes LV-CG great, then let's make them contribute to growing the LV-CG eco-system.

 

edit :

if you agree >> https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-NXG-dev-team-contribute-to-LV-related-open-source-projects/idi-p/4110996

I think the NXG team was outsourced to a C# dev house outside of the US. I suspect the contract has been terminated.

Link to post

My understanding is that NXG is a full platform effort, not just LabVIEW.  The LabVIEW part was scrapped, not everything else.  I suspect the devs for LabVIEW NXG have already been moved on to work on Instrument Studio, TestStand (2020 has the NXG look), VeriStand, Flex Logger, etc.

Link to post
  • 2 weeks later...
On 1/7/2021 at 1:32 PM, Neil Pate said:

I think the NXG team was outsourced to a C# dev house outside of the US. I suspect the contract has been terminated.

My informations from inside NI is that this is largely untrue.

NXG team will be re-assigned to other projects and a large part focusing on non-Windows OS support 😮

I don't have much details but different sources corroborate this.

Edited by Antoine Chalons
  • Like 1
Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.