Just Downloaded and Installed LabVIEW NXG.....

[mje]

14 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?

At the risk of veering further off topic, we some times use an arduino or the like to bang out a quick proof, but you're right in that these never make it into anything real.

The idea is that the microcontrollers that these platforms are based on have a many peripherals that can do most of the common operations I need to do in hardware without the need for an FPGA. For most of my applications a 100 MHz 32-bit CPU is serious horsepower when I have the heavy lifting offloaded to the peripheral hardware. When the on board peripherals are insufficient there's literally over a dozen communication options, often with several instances of each never mind the ability to tap right into the system bus on the more sophisticated µC architectures. Need to upgrade up the ADC? Fine, that's a $15 IC that will tap into the SPI bus. Easy. Repeat for a few other obscure needs that the built-in stuff can't handle and when all is said in done I have a board that does exactly what we need and costs maybe $200-$500 per unit at volumes of 10-25.

While I have no problem building a single $5,000 NI platform to test something, scaling the volume is sometimes a hard sell. What happens when we need to make 5 more to move from proof to concept? Then 25 more to ship around the world for collaborators to test and bang on for a bit? It's hard to sweep numbers like that under the rug for lower visibility projects, but even for the high ones where it could fly, how do I fit one of those NI boxes in my widget that's supposed to be smaller than any of the NI chassis (except the SOM, obviously)

Edited June 1, 2017 by mje

[smarlow]

I still remember the "LabVIEW Everywhere!" marketing campaign of 2004.  The IOT realm was going to be ruled by LabVIEW, and soon we would use it to program toasters.   Then the embedded module went the way of the dodo, and now it is everywhere except there, and there, and over there, of course.

Edited June 1, 2017 by smarlow
typo

[ASTDan]

Is there any beginner guides, Training material or any thing other than a 2 minute video for LabVIEW NXG?

[hooovahh]

If you have an active SSP (not sure how you'd get NXG without it) then you should have access to the Self-Paced Online training.  No idea how much it covers or how well it is put together.

http://sine.ni.com/myni/self-paced-training/app/main.xhtml

It looks like they have a Core 1 with Acquire Analyze Present, and another set of sessions on transitioning to NXG 1.0.

[Rolf Kalbermatter]

On 5/25/2017 at 8:13 PM, smarlow said:

I'd like to know what the long-term plans are, as well.

There was some assurance in the past that classic LabVIEW will remain a fully supported product for 10 years after the first release of NXG. Having 1.0 being released this NI Week would end LabVIEW classic support with LabVIEW 2026.

And yes .Net is a pretty heavy part in the new UI of LabVIEW NXG (the whole backend with code compiler and execution support is for the most part the same as in current LabVIEW classic). Supposedly this makes integrating .Net controls a lot easier, but it makes my hopes for a non-Windows version of LabVIEW NXG go down the drain. Sure they will have to support RT development in LabVIEW NXG, which means porting the whole host part of LabVIEW RT to 64 bit too, but I doubt it will support more than a very basic UI like nowadays on the cRIOs with onboard video capability. Full .Net support on platforms like Linux, Mac, iOS and Android is most likely going to be a wet dream forever, despite the open source .Net Core initiative of Microsoft (another example of "if you can't beat them, embrace and isolate them") 

[ShaunR]

22 minutes ago, rolfk said:

Supposedly this makes integrating .Net controls a lot easier, but it makes my hopes for a non-Windows version of LabVIEW NXG go down the drain.

I don't think that is the strategy. I think the intention is to only have to deal with one OS on all NI platforms (Windows everywhere).

[Rolf Kalbermatter]

6 minutes ago, ShaunR said:

I don't think that is the strategy. I think the intention is to only have to deal with one OS on all NI platforms (Windows everywhere).

That would mean to trash NI Linux RT and go with a special variant of Windows RT for RT (sic). I'm not yet sure that NI is prepared to trash NI Linux RT and introduce yet another RT platform. But stranger things have happened.

[lordexod]

.Net is open source, apart from the WPF platform, to ported NXG to other systems, writing again the WPF native components such as: MilCore and compiler DFIR to LLVM instead of lvffrt.

[Rolf Kalbermatter]

1 hour ago, lordexod said:

.Net is open source, apart from the WPF platform, to ported NXG to other systems, writing again the WPF native components such as: MilCore and compiler DFIR to LLVM instead of lvffrt.

No, .Net Core is open source, but .Net is quite a different story. And the difference is akin to saying that MacOS X is open source, because the underlying Mach kernel is BSD licensed!

[ShaunR]

2 hours ago, rolfk said:

That would mean to trash NI Linux RT and go with a special variant of Windows RT for RT (sic). I'm not yet sure that NI is prepared to trash NI Linux RT and introduce yet another RT platform. But stranger things have happened.

NI already have a Windows RT platform that they distribute with their PXI racks. I don't think it would be a great leap from that, especially when M$ are pushing previous Windows Embedded systems to Windows 10.

[infinitenothing]

I'm guessing they are going to handle that by having the option of an HTML UI. There was some hinting of LabVIEW to javascript in prior keynotes.

Edited June 2, 2017 by infinitenothing

[Rolf Kalbermatter]

2 hours ago, ShaunR said:

NI already have a Windows RT platform that they distribute with their PXI racks. I don't think it would be a great leap from that, especially when M$ are pushing previous Windows Embedded systems to Windows 10.

Windows RT and Windows Embedded are two very different animals. Windows Embedded is a more modular configurable version of Windows x86 for Desktop while Windows RT is a .Net based system that does contain a kernel specifically designed for a .Net system, without any of the normal Win32 API interface.

Windows Embedded only runs on x86 hardware ,while Windows RT can run on  ARM and potentially other embedded CPU hardware. On the other hand Windows Embedded can run .Net CLR applications and x86 native applications, while Windows RT only runs .Net CLR applications. RT here doesn't stand for RealTime but is assumed to refer to the WinRT system, which basically uses the .Net intermediate code representation for all user space applications to isolate application code form the CPU specific components. Windows RT officially was only released for Windows 8 and 8.1 but the new Windows S system that they plan to release, seems to be build on the same principle, strictly limiting application installation from Microsoft Store and only for apps that are fully .Net CLR compatible, meaning they can't really include CPU native binary components.

These limitations make it hard for anyone to release hardware devices based on this architecture as only Microsoft Store apps are supported. But I think NI might be big enough to negotiate a special deal with Microsoft for a customized version that can install applications from an NI App Store . Perfect monetization!

However with the track record Microsoft has with Windows CE, Phone, Mobile, RT and now S, which all but S (which still has to be released yet) were basically discontinued after some time, I would like to think that NI is very weary of betting on such an approach.

For the current Realtime platforms NI sells I would guess that ARM support is still pretty important for the lower cost hardware units, so use of Windows Embedded alone is not really feasible  If NI could use the Windows RT based approach for those units, they might get away with implementing an LLVM to .Net IL code backend for those, but since Windows RT is already kind of dead again, that is not going to happen.Therefore I guess NI Linux RT is not going away anytime soon.

58 minutes ago, infinitenothing said:

I'm guessing they are going to handle that by having the option of an HTML UI. There was some hinting of LabVIEW to javascript in prior keynotes.

Yes the new WebVI technology based on HTML5 is likely the horse NI is betting on for future cross platform UI applications that will also run on Android, iOS and other platforms with a working web browser. Development however is likely going to be Windows only for that for a long time.

Edited June 2, 2017 by rolfk

[Aristos Queue]

On 6/1/2017 at 4:45 AM, Nikita Prorekhin said:

When designing in Visual Studio, you can choose between WYSIWYG, XML or split design modes.

Is it possible to do the same in NXG?

Split design mode, yes, where you can see both panel and diagram. We don't maintain an in-memory XML form, and if you look at the save files, directly editing the XML is a fools' errand (at least for me... I've tried to doctor several such files over the last few years). So if you're asking for an XML format, there isn't one.

[Aristos Queue]

53 minutes ago, rolfk said:

Yes the new WebVI technology based on HTML5 is likely the horse NI is betting on for future cross platform UI applications that will also run on Android, iOS and other platforms with a working web browser. Development however is likely going to be Windows only for that for a long time.

This theory is correct. (I'm just the messenger. If you want cross-platform development, talk to your local NI sales engineers and other NI feedback venues.)

[Aristos Queue]

6 hours ago, rolfk said:

There was some assurance in the past that classic LabVIEW will remain a fully supported product for 10 years after the first release of NXG. Having 1.0 being released this NI Week would end LabVIEW classic support with LabVIEW 2026.

The latest guidance, given to both customers and to LV R&D: development in the current platform will be increasing and will continue for the next few years. Not just bug fixes, but actual feature development. When NXG reaches maturity such that it is capable of being a full replacement for the current platform, it will be renamed as just "LabVIEW" and the current platform will move to some other name, TBD. That "full replacement" version is what some people call the "parity release", although parity is a bit of a misnomer since some features are being deliberately left in the past (front panel data socket, "Enable Database" on subVIs, to name two). If you hear about NXG reaching parity, it means the point where our most advanced customers can fully do their jobs with a UI that they're at least grudgingly happy about (Hoovah's graph of user happiness earlier in this thread is quite accurate, IMHO).

From that rename point, there will be several years of support for the current platform: limited bug fixing and validation for new OS editions as they occur. How many years exactly will be communicated at that time, but it will be multiple.

That's the summary. Now, to put some details behind that...

I personally have at least 2 years worth of new features in the pipe. My personal attention is split, with about 15% to NXG and 85% to LabVIEW. There are a couple of teams with 2018 features, and I'm expecting to see a few more on-boarding for that and 2019. The majority of developers will still be working on NXG, but we will see a lot more life in LabVIEW.

The new features will mostly (but not exclusively) focus on language developments, not editor developments. The language enhancements of channels and malleable VIs are both going to see improvements going forward. There are four new structure nodes being kicked around, one of which you've seen if you've seen the NIWeek or CLA Summit presentation on 2017 malleable VIs. For the other three, ask @lordexod... long experience tells me he's probably discovered their early footprints in the code. ;-) 

I said there would not be many editor developments. That's because the whole inspiration for NXG was to provide a new editor because the code in the current environment makes editor enhancements particularly cumbersome (30+ years of development makes for a lot of module coupling). Given that, it makes little sense to try to forge ahead with most editor improvements. But there are some editor enhancements that are worth doing, as you see from the live drag and the remove space enhancement of the last couple versions. There will be more ahead.

Because the compiler and execution engine are shared between LabVIEW and NXG, there's a team working on optimizations to both of those, so you'll see improvements in those areas. The interest in improving run-time load speed has lead people to discover ways to improve load speed in the current editor... you'll see some of those improvements in 2017, more in 2017 SP1, and another few in 2018.

That's as much signposting of the road map as I can give at this time. I hope this information provides at least some reassurance to the LAVA community.

[ShaunR]

4 hours ago, rolfk said:

These limitations make it hard for anyone to release hardware devices based on this architecture as only Microsoft Store apps are supported. But I think NI might be big enough to negotiate a special deal with Microsoft for a customized version that can install applications from an NI App Store . Perfect monetization!

Well .There is also Windows 10 IoT but the intent seems to be  one OS to rule them all and they (M$) have stated so.We shall see whether it is just a rebranding to Windows 10 of different OSs or a more micro kernel approach with .NET at the centre.  Regardless. M$ have proven their disregard for privacy so from my perspective it makes no difference.

4 hours ago, rolfk said:

Yes the new WebVI technology based on HTML5 is likely the horse NI is betting on for future cross platform UI applications that will also run on Android, iOS and other platforms with a working web browser. Development however is likely going to be Windows only for that for a long time.

Well I've been using browsers for a long time now and there are caveats here. A browser JS engine is single threaded and usually buckles with more than a few hundred KB/s. They also tend to only run the JS in the tab that is front-most. A cursory glance at some of the demo videos it appeared to just be a HTML and Javascript editor (maybe an embedded engine too) in the UI and probably the usual NI Webserver somewhere in the background as they were using HTTP requests. I didn't see any use of HTTPS which really should be de-facto nowadays. If that's all it is then I'm no better off than now only currently I can also use Websockets and WebRTP et. al. Perhaps I'm jumping the gun here, though. But I will be looking very closely at this in the next couple of weeks to see exactly what's there.

[ShaunR]

@AQ.

What is the advice for Toolkit developers? Where does the tools network fit in with this new software?

Edited June 3, 2017 by ShaunR

[Rolf Kalbermatter]

2 hours ago, ShaunR said:

 

Well .There is also Windows 10 IoT but the intent seems to be  one OS to rule them all and they (M$) have stated so.We shall see whether it is just a rebranding to Windows 10 of different OSs or a more micro kernel approach with .NET at the centre.  Regardless. M$ have proven their disregard for privacy so from my perspective it makes no difference.

Well Windows IoT must be based on Windows RT or its successor, as the typical IoT devices do not use an Intel x86 CPU, but usually an ARM or some similar CPU.

And looking at the Windows IoT page it says:  Windows 10 IoT Core supports hundreds of devices running on ARM or x86/x64 architectures.

Now I don't think they can limit that one to MS Store app installs only, so they must not use that restriction on IoT, but technically it would seem to be based on the same .Net centric kernel than Windows RT. And in order to provide the taunted write once and run on all of them, they will push the creation of .Net IL assemblies rather than any native binary code, Maybe it's not even possible to use native binary code for this platform. At some point they did promise an x86 emulator for the Windows RT platform (supposedly slated for a Windows RT 8.1 update) in order to lessen the pain of a very limited offering in the App Store, but I don't think that ever really materialized. CPU architecture emulation has been many times tried and while it can work, it never was a real success, except for the 68k emulator in the PPC Macs, which worked amazingly well for most applications that didn't make use of dirty tricks. 

[lordexod]

This may the next version of NXG 3.0 will make it on Windows MR (MixedReality)?

 

[Aristos Queue]

On 6/2/2017 at 7:09 PM, ShaunR said:

@AQ.

What is the advice for Toolkit developers? Where does the tools network fit in with this new software?

You'll have to make your own call on when to add support for the new and when to drop support for the old. That's my only guidance. The LabVIEW Tools Network team may have more specific feedback. You can ask them on the toolkit dev forum: http://forums.ni.com/t5/LabVIEW-Tools-Network-Developer/ct-p/7009

[Mads]

On 5/30/2017 at 1:07 AM, hooovahh said:

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).

Apparently the CG term is not supposed to be used. I would personally prefer to have an explicit way of referring to the...non-NXG versions, but the official names are LabVIEW and LabVIEW NXG.

Edited June 6, 2017 by Mads

[smidsy]

On 6/2/2017 at 9:21 PM, Aristos Queue said:

Split design mode, yes, where you can see both panel and diagram. We don't maintain an in-memory XML form, and if you look at the save files, directly editing the XML is a fools' errand (at least for me... I've tried to doctor several such files over the last few years). So if you're asking for an XML format, there isn't one.

Hi Aristos,

Thanks, good to know this!

Other questions (very trivial I guess) that came to my mind:

1. Is it possible to configure the size of a Panel? Restrict resizing?

2. I opened one of the examples and zoomed out. Why do I have the white space around my UI and then the gray space (I suppose the limits of my panel)?

 

3. How should zooming feature on front panels work in a compiled application? Would it be possible to control it programmatically (restrict or allow zooming, zoom to a specific value)? 

Am I alone seeing new panels a little bit strange?

 

[Mads]

Nikita, have you signed up for the 2.0 beta? 

Having cooled off a bit about the decisions NI has made with NXG, I'm spending more time in testing it (even though it is not supposed to cover many our needs for many years to come I do not want to have to start from scratch then), and providing feedback to NI (I'll probably fill up their in-box ) in forums and through the in-built (did not find it at first, it's the talking bubble at the top right) feedback function.

[Aristos Queue]

13 hours ago, Nikita Prorekhin said:

Other questions (very trivial I guess) that came to my mind:

You'd have to ask a NXG UX designer those questions. All my NXG work is behind the scenes. I don't speak for any of the design decisions of anything you see on screen. In some cases, I can tell you "what" but rarely can I tell you "why". Try posting your questions to the CAB forum or use the feedback function that Mads mentioned above.

Edited June 7, 2017 by Aristos Queue

[Deon]

Went an NI seminar on NXG recently and the app engineers have indicated that the two versions of labview will continue side-by-side for the foreseeable future, with the NXG continuing as a separate application.

FWIW