Jump to content

Just Downloaded and Installed LabVIEW NXG.....


Recommended Posts

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 by mje
  • Like 2
Link to comment

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 by smarlow
typo
  • Like 2
Link to comment

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.

Link to comment
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") 

Link to comment
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).

Link to comment
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.

Link to comment
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!

Link to comment
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.

Link to comment
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 :ph34r:. 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 by rolfk
Link to comment
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.

Link to comment
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.)

Link to comment

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 :ph34r:. 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.

Link to comment
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. 

Link to comment
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

Link to comment
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 by Mads
Link to comment
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)?

 nxg-panel.png

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? :)

 

Link to comment

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 :blink:) in forums and through the in-built (did not find it at first, it's the talking bubble at the top right) feedback function.

Link to comment
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 by Aristos Queue
Link to comment
  • 2 months later...

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

Link to comment

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.