Just Downloaded and Installed LabVIEW NXG.....

[ShaunR]

2 hours ago, smithd said:

I would assume its due to c# being the nicest of the top languages to use for a desktop program and everyone wants to make development more efficient. Python and JS I think you can easily throw out for large projects, PHP is web, and java's popularity is with back-end applications not desktop programs (I don't have java installed at home or at work, and I'd have to really want to use the program to install it). So that leaves c++ or c#, and I think you'll have trouble finding people who think they are more productive in 'cross platform' c++ vs c#. 

Linux has its own cross-platform problems. I don't know how you navigate these issues, but when I want to try out programs that are linux-only I constantly have issues where instructions for install are restricted to 1 or 2 flavors of linux (presumably 'the developers run fedora so we have instructions for fedora' and the other flavors have either no instructions, out of date instructions, or out of date builds. So I end up with several VMs of different linux types rather than 1 VM for playing around. I know bigger projects like the dbs, xilinx, etc don't have these issues, but big project have support everywhere.

Well. LabVIEW was the best cross development platform. That is why I used it. I could develop on Windows and, if I managed to get it installed, it would just work on Linux (those flavours supported). Over time I had to write other cross platform code that LabVIEW couldn't do or, rather, wrote cross platform code so that LabVIEW could use it on other platforms. I used the Codeblocks IDE (GCC and MingW compilers) for C and C++ DLLs or the Lazarus IDE for Free Pascal (in the form of Codetyphon). The latter can use several GUI libraries such as QT, GTK through to Windows or its own fpGUI. However. those things aren't the problem with Linux. It is the distribution and the Linux community is in denial (still) that there is a problem.

So recently I have had a pet project which was a "LabVIEW Linux" distribution. I created my own distro where I could ensure that no other idiot could break the OS just because they decided to be "cool" or wanted to use "this favourite tool". I basically froze a long term support and tested distro, added all the tools I needed, removed all the "choice" of what you could install then made it into a custom distro that I could micro-manage updates with (like OpenSSL), It had LabVIEW, VISA and DAQ installed, along with a LAMP, and all my favourite LabVIEW tool-kits were pre-installed. It could be run as a live CD and could be deployed to bare bones PCs, certain embedded platforms and even VPS. I solved (or added to )the distribution problem by making my own.

Here's a funny anecdote. I once knew of a very, very large defence company that decided to rewrite all their code in C#. They tried to transition from C++ on multiple platforms to C# but after 6 years of re-architecting and re-writing they canned the project because "it wasn't performant" and went back to their old codebase.

Edited May 29, 2017 by ShaunR

[smithd]

1 hour ago, ShaunR said:

Here's a funny anecdote. I once knew of a very, very large defence company that decided to rewrite all their code in C#. They tried to transition from C++ on multiple platforms to C# but after 6 years of re-architecting and re-writing they canned the project because "it wasn't performant" and went back to their old codebase.

This is a pretty famous problem within large projects, as with netscape, word, mozilla, etc: https://news.ycombinator.com/item?id=2139176 or https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

I'm not convinced that NI hasn't done the same to themselves by neglecting their existing customers in favor of...whoever ngx is supposed to benefit...but I don't think you can blame the language, especially one as large as c# (which includes the core language, the base libraries on top of it, and then the ui frameworks asp/wpf/winforms). I'm sure there are similar anecdotes of people who moved from c to c++ and it was 'too slow', or people who never got their product to market because they spent too much time trying to understand their c++ compiler errors.

1 hour ago, ShaunR said:

Well. LabVIEW was the best cross development platform. That is why I used it. I could develop on Windows and, if I managed to get it installed, it would just work on Linux (those flavours supported).

Fair enough -- one thing I wondered is why they havent gotten around to cross compilation now that the compiler is llvm. Clearly they know how to cross compile -- they do pharlap, linux-arm, linux x64, and VxWorks without too much of a problem...but no obvious cross-compile for desktops.

[JKSH]

1 hour ago, smithd said:

one thing I wondered is why they havent gotten around to cross compilation now that the compiler is llvm. Clearly they know how to cross compile -- they do pharlap, linux-arm, linux x64, and VxWorks without too much of a problem...but no obvious cross-compile for desktops.

I'm guessing it has something to do with the pricing of Application Builder -- NI is selling these for $1500.

It's not clear to me: Does purchasing the license of Application Builder for one OS entitle you to the other OS'es...? Also, does the Developer Suite entitle you to LabVIEW on all desktop OS'es?

[Mads]

4 hours ago, smithd said:

This is a pretty famous problem within large projects, as with netscape, word, mozilla, etc: https://news.ycombinator.com/item?id=2139176 or https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

I'm not convinced that NI hasn't done the same to themselves by neglecting their existing customers in favor of...whoever ngx is supposed to benefit.

Did you just read my mind? Perhaps I was reading yours 

<Old man (well, middle aged) yelling at the sky>
We have been waiting for major upgrades of LabVIEW for years, and after so many years without much progress it turns out NI has really just abandoned the ship to build a different one, not sail-worthy until 2020. Where does that leave LabVIEW TG (This Generation) but dead in the water?  The road map does not exactly encourage us to base our business on it. We either spend time and money on staying updated on the next generation stuff for many years until it actually can replace this generation, or move away from NI. Frankly I would have preferred it if they kept us in the dark, working on NextGen for another 4 years until it had reached "parity", and only *then* told the world about it.
</Old man yelling at the sky>

[ShaunR]

6 hours ago, smithd said:

This is a pretty famous problem within large projects, as with netscape, word, mozilla, etc: https://news.ycombinator.com/item?id=2139176 or https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

I'm not convinced that NI hasn't done the same to themselves by neglecting their existing customers in favor of...whoever ngx is supposed to benefit...but I don't think you can blame the language, especially one as large as c# (which includes the core language, the base libraries on top of it, and then the ui frameworks asp/wpf/winforms). I'm sure there are similar anecdotes of people who moved from c to c++ and it was 'too slow', or people who never got their product to market because they spent too much time trying to understand their c++ compiler errors.

Fair enough -- one thing I wondered is why they havent gotten around to cross compilation now that the compiler is llvm. Clearly they know how to cross compile -- they do pharlap, linux-arm, linux x64, and VxWorks without too much of a problem...but no obvious cross-compile for desktops.

I don't blame the language. C# is just a front end for .Net (like VB.net et. al.) It's the .Net I blame and have always blamed and I don't care what language you put in front of it including LabVIEW - It will be worse.

But there is more to this than a language choice. It is quite clear than NI have jumped in with both feet onto the Windows 10 platform which, don't forget, is attempting to corner all hardware platforms with one OS. There is some sense in that since Win 10 has JIT compilation of .NET (perfect for VI piecemeal compilation) , a background torrent system (push deployment and updates whether you like it or not) and plenty of ways to get data for mining and DRM enforcement (Customer Improvement Programs). This is the start of Software As a Service for NI so you won't need LabVIEW in its old form.

[hooovahh]

15 hours ago, Mads said:

We have been waiting for major upgrades of LabVIEW for years, and after so many years without much progress it turns out NI has really just abandoned the ship to build a different one, not sail-worthy until 2020. Where does that leave LabVIEW TG (This Generation) but dead in the water?  ... Frankly I would have preferred it if they kept us in the dark, working on NextGen for another 4 years until it had reached "parity", and only *then* told the world about it.

While at NI Week I forgot to ask someone in R&D if they have been purposely providing one major new feature in CG (current gen is the term I've heard more often).  And if so how long has that plan been around.  VIMs are awesome and cool but has NI had that feature on their road map for 2017 release?  And Channel Wires for 2016, right click 2015, etc?  My only thoughts are I wouldn't be surprised if NI knew they had to have at least one new feature worth talking about each year, while resources were likely shifting to NXG.

As for the message and release dates, I don't agree that releasing the finished product in 2020 (assuming parity is then with your example) would have been the best approach.  Even with the non completeness, I can tell you I will be using NXG 2.0 (possibly the already released beta) for an actual real project.  Until there is parity I don't mind using one IDE with its strengths, and the other for what it does well.  Also I've actually heard some complain that NI didn't start putting alphas out and getting the opinion of others sooner.  The thought process was NI maybe already made some key decisions before the those outside of NI could make suggestions for improvement.  Now if NI was ready to hear that feedback, or make improvements based on it is another discussion.

[Mads]

7 hours ago, hooovahh said:

Also I've actually heard some complain that NI didn't start putting alphas out and getting the opinion of others sooner.

Sure, trying to get feedback from people on something in beta already that has already been changed as dramatic as NXG is rather unfruitful...it's too much too late. Especially if most of the users that might have feedback for it stay away because of previously signed NDAs. We could always dream of access and influence at every stage, and hope that our personal views won the battles, but I do not think that would be productive.

In general revealing too much about future products is bad for business (in this case for both customers and NI). If the news is about future *updates*, you have a positive effect though. Then people know that they will gradually get more and more out of their investment, they will not need to throw the old cell phone in the bin and buy a new one to get access to a new feature.You could say that because NXG is given to existing owners of LabVIEW CG (not sold as a separate product, that would have been terrible) it could be consideres an update, but it's more like halting the development of the software on your existing cell phone, and giving you a new one with some new features...but unfortunately you cannot use it to phone anyone for the next couple of years (use it on your cRIO projects for example). So now you have access to some new features, but you have to carry around two phones...

[lordexod]

In LV NXG you have more capabilities than you had in LV TG because you can make abstraction layer for XNode, XDiagram, XTunnel, XWire, components as native plugins.

 

[ShaunR]

5 hours ago, Mads said:

Sure, trying to get feedback from people on something in beta already that has already been changed as dramatic as NXG is rather unfruitful...it's too much too late. Especially if most of the users that might have feedback for it stay away because of previously signed NDAs. We could always dream of access and influence at every stage, and hope that our personal views won the battles, but I do not think that would be productive.

In general revealing too much about future products is bad for business (in this case for both customers and NI). If the news is about future *updates*, you have a positive effect though. Then people know that they will gradually get more and more out of their investment, they will not need to throw the old cell phone in the bin and buy a new one to get access to a new feature.You could say that because NXG is given to existing owners of LabVIEW CG (not sold as a separate product, that would have been terrible) it could be consideres an update, but it's more like halting the development of the software on your existing cell phone, and giving you a new one with some new features...but unfortunately you cannot use it to phone anyone for the next couple of years (use it on your cRIO projects for example). So now you have access to some new features, but you have to carry around two phones...

If you think of it more as a replacement for MAX with a VI editor built in, then it may make a lot more sense than a new LabVIEW. There is a very obvious emphasis on distribution, system configuration and deployment-many of the things that MQTT is doing for maker boards and IoT devices. I don't think it is a coincidence that wireless are among the first products to be supported rather than cRIO type devices.

Interestingly I also think it is a case of be careful what you wish for. I have asked for many years for source code control applicable to LabVIEW because other SCC treat Vis as binary blobs (good luck with that merge ) So really we could only use them for backup and restore. Well. Now LabVIEW Vis are text (XML it seems) so it is absolutely possible to, in theory, do diff merges. I also have complained about creating custom controls. Well. We will have that now too via C#.

So I can write IDE controls and project plugins in C#. I can bind to the NI assemblies (in C#) for DAQ and Instrument Control. I can use SVN with C# so what do I need LabVIEW for?

If you *want* to use LabVIEW then there is an IDE, although rehashing all the icons will only alienate existing LabVIEW programmers. We will be inferior to C# ones because we can only do a subset of their capabilities on our own platform. Over time, NI customers will not renew their LabVIEW SSP packages which gives NI the excuse to not support it. All the experienced LabVIEW programmers will either move to something else because no jobs are available (see my previous comment about Python in T&M) or retire. Large corporations will be hiring C# programmers to rewrite the LabVIEW code that failed conversion. Then ..... it gets worse

The best we can ask for at this point is that NI open source LabVIEW 2017 and give it to the community as a going away present :.

[hooovahh]

21 minutes ago, ShaunR said:

Well. Now LabVIEW Vis are text (XML it seems) so it is absolutely possible to, in theory, do diff merges. I also have complained about creating custom controls. Well. We will have that now too via C#.

You see people say this, but I'm not sure it will be true.  The reason merge works on text languages is because sections of the code will be edited by different users.  Maybe a subfunction in a file I modify, and a different function in a different section is modified by another user.  The merge can then realize the changes between the two and make one file that contains both changes.  The reason this works well is because in the file these two separate parts of the file are not linked and independent.

I haven't looked at the XML structure much yet, but lets say each object has an offset from origin, telling it where it should be on the block diagram.  If I perform a select all, and then move them one pixel to the right, every object in the file now has been modified, and it would be more like editing every line in a file in my text based language example.  If you then make some other change to the code, the automatic merge will see we both changed the same line of code.  And even doing this in a text based language means reviewing the changes and understanding how the merge should proceed.  I suspect that in the real world parts of the file maybe modified in ways that effects lots of objects, which will complicate the merge.

I don't think the XML file will solve our problems with automatic merge in SCC, but I do think it is an improvement over the binary blob of CG.

6 hours ago, Mads said:

You could say that because NXG is given to existing owners of LabVIEW CG (not sold as a separate product, that would have been terrible) it could be consideres an update, but it's more like halting the development of the software on your existing cell phone, and giving you a new one with some new features...but unfortunately you cannot use it to phone anyone for the next couple of years (use it on your cRIO projects for example). So now you have access to some new features, but you have to carry around two phones...

Yeah I think NI had no choice when it came to the cost of NXG, they simply could not charge extra for it at this point.  If it were a separate stand alone product, with its own cost and SSP, this thread would probably have a totally different tone.  And as I mentioned already, NXG 1.0 is not a product marketed for us.  If you are doing a simple USB DAQ with acquire, analyze, present, and you know your scope won't grow, it isn't a bad product.  The integration of MAX features, is also pretty cool.  For most things you shouldn't need a separate application to just confirm hardware is working, opening test panels, taking data, etc.  Basic system integration stuff before you are writing code.  Not that I had many complaints about MAX but I can see why you might want a single experience.  Oh and I heard someone say that MAX isn't going away just yet.  There still will be some features MAX does that the System Designer and NXG won't do.  Not sure what the long term plan is.

[Mads]

If you think of it more as a replacement for MAX with a VI editor built in, then it may make a lot more sense than a new LabVIEW.

That's a pretty good description of how it feels to me too. A fancy interactive configuration tool, first and foremost. We're back to the "no programming", NI Hardware-centric marketing dream, and not the fun graphical cross-platform programming environment that can be used for general application development. Windows Metro for the desktop comes to mind too...

One of the first things that bugs me when working in NXG 1.0, and unfortunately 2.0 as well, is the whole concept of having everything in one window. It's claustrophobic, and feels like I'm stuck in - you said it, NI MAX...I want to break out those front panels, view them as I would want them in my built application throw some of the block diagrams to another screen to do some debugging while interacting with the front panel at the same time. Get rid of all the overhead of the surrounding interface etc...I can see how you can make multiple complete IDE tabbed windows, but where is the WYSIWYG for built applications in that?

Previously I considered what NI did with G/LabVIEW to be similar to what Apple did with MacOS; they created a revolutionary environment that made it much more intuitive and fun to use computers/develop applications (and just like with the Mac, only the smartest people understood that this was the future ). It did mean that there were limits as to what you could achieve...and we've all been spending lots of time trying to work around those for years...(hoping to get better native graph controls and a few thousand other things) but there was enough functionality and flexibility there to make the joys of graphical programming worth it. The last couple of years I've found myself frustrated by the fact that things seemed to move backwards/away from that philosophy with things like Linux RT; gone were the days when everything was available wrapped in a nice graphical interface; I suddenly found myself writing bash (!)-scripts to get even quite basic stuff done. 

When I saw the demo of the web functionality in NXG 2.0 I got some of the same feeling; In the good old days (yeah yeah) I would not have expected it to be seen it as a positive that the HTML-code was just around the corner....to me the whole concept of LabVIEW is to provide a 100% graphical editor, it should allow you to do 99% of what you want to do *graphically*. The HTML should be accessible too, sure, but not "in your face". Has the text programmers behind LabVIEW gotten too much influence? Thinking that LabVIEW is really just for non-programmers (so you really need to make it a configuration tool instead), and if you want to do some real programming you should work like they do - with text, and an IDE as close to the ones they are used to as you can get? Oh well, perhaps I should cool off ....and force myself to test it more, or maybe not (so far that has made me angry pretty quickly). 

[smithd]

2 hours ago, hooovahh said:

I haven't looked at the XML structure much yet, but lets say each object has an offset from origin, telling it where it should be on the block diagram.  .

I was just thinking about this too. I believe at present this is right, but it seems like it would make sense to separate the logical linkages from the decorations. I mean the 'code' is just the nodes and wires. We want to describe the appearance of those too but its completely irrelevant to the 'code'.

1 hour ago, Mads said:

it should allow you to do 99% of what you want to do *graphically*. The HTML should be accessible too, sure, but not "in your face". 

I'm sure this is still an eventual goal, but the stuff they mentioned with regards to editing the html manually was all relatively specific and advanced, like dropping in an embedded youtube or maps element. I would assume that the next first step would be a drop down "script control", etc. etc.. I suppose they could use this as a crutch to avoid developing features, but I'd much rather be able to fix an issue by editing the html than relying on NI to fix a bug and push a patch.

Edited May 30, 2017 by smithd

[DTaylor]

12 hours ago, lordexod said:

In LV NXG you have more capabilities than you had in LV TG because you can make abstraction layer for XNode, XDiagram, XTunnel, XWire, components as native plugins.

Is this speculation about something that you think we should be able to do in NXG, or is this functionality that you've heard is actually planned?

[Mads]

The MDI/tabbed interface solution for VIs seems to be one of the most fundamental flaws of NXG GUI.

One of the biggest strengths of LabVIEW CG is that it enables and encourages continuous testing. You can have the user interface of your VIS (the whole application you are building for that matter) *on screen*, shown as it will be when built, not as a page within an MDI interface) and provide input to it and view the output - while you at the same time view and change the code of various VIs...tweak, run (as soon as the code is not broken), input, view output, tweak, run...etc. Just the idea that it is OK to require the developer to manually tab between the front panel and the code is ridiculous. It is scary how they can think that's a good change in the work flow, but then again - the text programmers are not used to much of what is (was) great in LabVIEW so that might explain why such things seem expendable. Now you can say that there are ways around this , or that it can be *fixed* in future versions of NXG - but the problem with that is that it would also require a complete redesign of the rest of NXG. There is too much stuff in NXG relying on it.

Do not get me wrong here - I would love it if someone told me wrong and showed me the NXG light. Where are all the NXG evangelists? What do the Knights of NI for example really think about NXG and the road ahead? Are they worried or even angry too, or do they think this is the best thing since sliced bread?

Edited May 31, 2017 by Mads

[ShaunR]

1 hour ago, Mads said:

The MDI/tabbed interface solution for VIs seems to be one of the most fundamental flaws of NXG GUI (It feels wrong to even point out one, as it might give the impression that the list is not huge, and that NXG should never have been made in the first place, but OK I'm leaving that part behind now. What is done is done).

One of the biggest strengths of LabVIEW CG is that it enables and encourages continuous testing. You can have the user interface of your VIS (the whole application you are building for that matter) *on screen*, shown as it will be when built, not as a page within an MDI interface) and provide input to it and view the output - while you at the same time view and change the code of various VIs...tweak, run (as soon as the code is not broken), input, view output, tweak, run...etc. Just the idea that it is OK to require the developer to manually tab between the front panel and the code is ridiculous. It is scary how they can think that's a good change in the work flow, but then again - the text programmers are not used to much of what is (was) great in LabVIEW so that might explain why such things seem expendable. Now you can say that there are ways around this , or that it can be *fixed* in future versions of NXG - but the problem with that is that it would also require a complete redesign of the rest of NXG. There is too much stuff in NXG relying on it.

Do not get me wrong here - I would love it if someone told me wrong and showed me the NXG light. Where are all the NXG evangelists? What do the Knights of NI for example really think about NXG and the road ahead? Are they worried or even angry too, or do they think this is the best thing since sliced bread?

The biggest problem for me was that they have changed all the wires. I spent about 10 minutes trying to figure out why a for loop wasn't self-indexing because a normal scaler value looks like a 1D array wire. At one point I was sure that it should've and was cursing that they had removed auto-indexing  Then I made the scaler into an array (which was a lot harder than it should have been) and it looked like a 2D array wire . I was probing around with the wiring tool tool trying to figure out what the wires actually were because my minds auto-parser just said everything wouldn't work. Add to that that all the primitive icons now look the same to me, only distinguished by some sort of braille dot encoding, I thought "I'm glad I won't ever have to use this". I think NI have recreated HPVEE to replace LabVIEW

Edited May 31, 2017 by ShaunR

[lordexod]

11 hours ago, DTaylor said:

Is this speculation about something that you think we should be able to do in NXG, or is this functionality that you've heard is actually planned?

How very you want you can do it XNode abstraction layer.

I personally prefer LV NXG from LV TG because I have 100% influence on what is implemented and for my future implementations.

For example, adding a Lattice FPGA platform because it has good and cheap FPGA ECP5.

Or simplify the implementation to XDiagram and XComponent so that I can create any diagram behavior for any component.

 

[hooovahh]

8 hours ago, Mads said:

Where are all the NXG evangelists?

They're at NI marketing.  I don't think anyone can make very well informed decision because so much of the platform is "Next version will have this feature, and fix this issue" and we can't really assess it until we have enough features to actually deploy a full real system, and find the things we like and dislike.  I also have concerns about much of what you mentioned.

8 hours ago, Mads said:

What do the Knights of NI for example really think about NXG and the road ahead? Are they worried or even angry too, or do they think this is the best thing since sliced bread?

I'll be presenting on NXG and 2017 in our next user group so I thought this might be a good time to illustrate what I call the NXG Cycle.

The thing to keep in mind here is some at NI, and some LabVIEW insiders have been seeing NXG since 2013 or earlier.  I've known about it but not for that long.  4 years or more of this cycle, all the while questioning all the current work you are doing and its relevance, can make for some very jaded feelings.  You tend to stop having high highs, and low lows, and instead are just ready for it to be finished so you can deal with the change.

[Mads]

I saw NXG through the tech preview, and there were a few of us that protested in the forums there.My hope was that it was mostly just experimentation,, not something they would release as it was. You have an optimistic view on things in the illustration. This time around I do not think it is just a question of users not wanting to change though. Every company making large changes can tell themselves that , and choose to insist on their planned direction, but quite often its just a bad product. There are positives with NXG (if it was the next generation of NI Max for example), but they do not justify and cannot outweigh the negatives (when supposed to be the next LabVIEW). This is the first time a release from NI has gotten me more interested in the competition than in the new NI products.

Edited May 31, 2017 by Mads

[ShaunR]

2 hours ago, hooovahh said:

They're at NI marketing.  I don't think anyone can make very well informed decision because so much of the platform is "Next version will have this feature, and fix this issue" and we can't really assess it until we have enough features to actually deploy a full real system, and find the things we like and dislike.  I also have concerns about much of what you mentioned.

I'll be presenting on NXG and 2017 in our next user group so I thought this might be a good time to illustrate what I call the NXG Cycle.

The thing to keep in mind here is some at NI, and some LabVIEW insiders have been seeing NXG since 2013 or earlier.  I've known about it but not for that long.  4 years or more of this cycle, all the while questioning all the current work you are doing and its relevance, can make for some very jaded feelings.  You tend to stop having high highs, and low lows, and instead are just ready for it to be finished so you can deal with the change.

Yeah, No. I've never seen a patronising waveform before .

That's not happening this time and probably hasn't happened for many years. We've seen LabVIEW stagnate with placebo releases and there are so many maker boards for less than $100, hell, less than $10, it's no longer funny (and you don't need $4000 worth of software to program them). I while ago I put a couple of Real-time Raspberry PIs in  system instead of NI products. You love Arduino, right?

There is a shift change in the availability of devices and the tools to program them and it has been hard to justify LabVIEW for a while now except if a company was already heavily locked in. If it's not working on Linux then that's a serious hobbling of the software since I, like many others, am now looking to expunge Windows due to privacy concerns for myself and my clients.

[hooovahh]

Not sure how a waveform can be patronizing.  Especially when it is an opinion of my own, based on my observations of...myself.

I'm not saying you are wrong (because you're not) but I am going to say you are seeming glossing over some of the positive things NI has been trying to do, to try to get into the cheaper hobbyist space.  Buying LabVIEW home for $50, which comes with application builder, and can deploy to Raspberry Pis as a target is a pretty positive thing that NI didn't need to do, that doesn't add direct positive revenue in terms of hardware sales.  And giving away the student for free is also nice.  I can't speak to the Linux LabVIEW thing, other than I've heard its poor.  My only experience with Linux in the last 13 years has been running Linux on NI hardware.  It's not something I've seen used in the testing career path I've been in, and I haven't needed it for the hobbyist projects I've had.  If Linux is important to you, NI is failing you because they seem to prioritize Windows.

Anyway I don't work for NI, I don't need to defend NI, and I don't know what NI has planned for the future.  I'm just trying to stay neutral and show some positives if some negatives are being highlighted (maybe I'm just on the sine wave coming down).  But I am not denying the valid negatives mentioned here.  I also want others to join in on the conversation.  No one wants to hear me spew the same opinion in different sets of words over and over.

[smithd]

20 hours ago, Mads said:

The MDI/tabbed interface solution for VIs seems to be one of the most fundamental flaws of NXG GUI.

You can have multiple windows with different tabs, and you can have a split-screen code/ui on one tab, so its certainly still possible to follow most of the same workflow. Like many people I like the tabbed interface and think its a significant improvement over the endless cascade of variable-size variable-position windows. How many times have you opened up someone else's code only to have it pop up off screen because they had more/bigger monitors than you? I've made a script to fix this on a folder of code, it happens so often.

Something else that may interest you is the data capture features, at least from a testing perspective: http://www.ni.com/documentation/en/labview/1.0/data/capturing-data/ and http://www.ni.com/documentation/en/tech-preview/1.0/data/using-analysis-panels-to-process-data/
When I actually get down to doing some math (eg analyze this waveform) I often end up tweaking things. The idea of being able to capture some representative data set, apply it to a math function, capture the output, tweak the math, capture the new output, and compare the results seems like a nice tool to have.

9 hours ago, ShaunR said:

That's not happening this time and probably hasn't happened for many years. We've seen LabVIEW stagnate with placebo releases and there are so many maker boards for less than $100, hell, less than $10, it's no longer funny (and you don't need $4000 worth of software to program them). I while ago I put a couple of Real-time Raspberry PIs in  system instead of NI products. You love Arduino, right?

This is an attitude that i remember hearing all the time and still interests me. I mean, an arduino, beaglepone, or raspberry pi is definitely cheap, but what can it actually do that you would otherwise use a cRIO for, or that would be generally useful in your work? I understand the hobby angle, but...what on earth did you use them for in your actual job?

Edited June 1, 2017 by smithd

[Mads]

6 hours ago, smithd said:

You can have multiple windows with different tabs, and you can have a split-screen code/ui on one tab, so its certainly still possible to follow most of the same workflow.

I mentioned workarounds in the post, and this in one of them. A bad one. You end up wasting way too much real-estate on this. Here's one for the NXG idea exchange; make a compact version of the IDE surround the panel/diagram (even make this part optional), and let larger items like the palettes magically appear at the cursor with a mouse-click ...oh, wait...).

6 hours ago, smithd said:

How many times have you opened up someone else's code only to have it pop up off screen because they had more/bigger monitors than you?

Not often. And NXG is like shooting yourself in the foot then, to get rid of a mosquito.

 

6 hours ago, smithd said:

Something else that may interest you is the data capture features, at least from a testing perspective: http://www.ni.com/documentation/en/labview/1.0/data/capturing-data/ and http://www.ni.com/documentation/en/tech-preview/1.0/data/using-analysis-panels-to-process-data/

None of these require NXG to be introduced. NXG would be a great new NI MAX, and some of its functionality would be great to have integrated into LabVIEW 2017/18 too. It's the whole other list of unnecessary changes and OK changes but released in an infantile NXG.
 

6 hours ago, smithd said:

This is an attitude that i remember hearing all the time and still interests me. I mean, an arduino, beaglepone, or raspberry pi is definitely cheap, but what can it actually do that you would otherwise use a cRIO for, or that would be generally useful in your work? I understand the hobby angle, but...what on earth did you use them for in your actual job?

I'm sure Shaun is spinning in his chair...but let me chime in here as well: Allow me to put the LabVIEW RT environment and run the same code as I use on Windows desktops (which is what we do today, thanks LabVIEW CG!) on a low power, low cost Linux SBC with plenty of serial IO and dual Ethernet (no such thing from NI other than the SOM, and then only if you design your own carrier board(!)) and I'll grab that opportunity over cRIOs faster than you can say NXG. Today we actually rip out the inside of cFP-2220's and put them in subsea instruments, just because that's the best option available unless we move away from LabVIEW.

Edited June 1, 2017 by Mads

[lordexod]

Personally, I would never ever implement a hundredfold shitty avr in fpga.

I would prefer something more interesting and useful like this: http://bar.eecs.berkeley.edu/projects/2014-rocket_chip.html

[smidsy]

On 5/31/2017 at 8:25 AM, Mads said:

The MDI/tabbed interface solution for VIs seems to be one of the most fundamental flaws of NXG GUI.

 

I feel uncomfortable with this too. But maybe I just need to get used to it. 

This is a screenshot of Microsoft Visual Studio designer:

When designing in Visual Studio, you can choose between WYSIWYG, XML or split design modes. It makes sense and it is very practical from my point of view. You can zoom in or zoom out on your application window, and you get the perspective of how it will look like.  

  

Is it possible to do the same in NXG?

Edited June 1, 2017 by Nikita Prorekhin
Missing question

[ShaunR]

59 minutes ago, Mads said:

I'm sure Shaun is spinning in his chair.

I've no idea what this means

7 hours ago, smithd said:

This is an attitude that i remember hearing all the time and still interests me. I mean, an arduino, beaglepone, or raspberry pi is definitely cheap, but what can it actually do that you would otherwise use a cRIO for, or that would be generally useful in your work? I understand the hobby angle, but...what on earth did you use them for in your actual job?

Well. It's a bit off topic but........

I used them for visual inspection. The RPi3 has a CSI-2 interface (many of these boards do). I think it was 4 lane (4Gbps) but I only needed two. You get wireless and HDMI for free. If you need a bit more processing power then you can add something like a Saturn FPGA for image processing (LX45, the same as in some of the cRIOs). The customer has tasked one of their engineers to investigate creating a GigE to CIF-2 converter because they eventually want to use and reuse Basler cameras on other projects but we were unable to find such a device (links please if anyone has them). They already had a LabVIEW program that they used a bit like NXG and I connected that to the sub system with wss Websockets.

For the ultra low end devices, I use them to add data logging, HMI and watchdog capabilities to existing hardware (like the Wago that was linked earlier and cRIO). You only need an Ethernet port and HDMI for that and as a bonus you get more USB ports. There is a whole multitude of choices here - with or without Wifi, LORA, more or less USB ports and GPIO etc. The only lacking technology at the moment is availability of GB Ethernet but they are starting to come through now.

These types of devices I no longer think of as "hobby" devices.

Edited June 1, 2017 by ShaunR