Maciej Kolosko

I was clumsy in my post. It was more about debugging clones, and the way the breakpoint system works in the IDE, and not about AF. I think AF is awesome, and fits well within LV. It is debugging of shared clones and multiple windows that drives me bananas sometime, and that is what I was trying to point out.

I think that depends on the use case. That was cool for me back in the days where I would write mostly 1off test code or stuff to support lab work. Meaning mostly non reentrant stuff connected to some form of NI Hardware to go along with it. But when building multi threaded applications with many reentrant shared clones etc. Having multiple windows pop up because of the awkward breakpoint system LV has It feels like the IDE it's trying to obfuscate the problem rather than help me zero in on it. It is quite difficult to have the dev system spawn 50 windows because a shared clone breakpoint has been hit, and since the wire values are not retained by default that is not even helpful in 98 % of the cases. So you either are going to click X a million time or go to cmd line and type taskkill /im LabVIEW.exe /f with great vengeance and furious anger. At this point I usually rely on a custom log to file solution to try and decipher what just happened, instead of having a whack a mole session, trying to find the actual window that makes sense to you in the context of what you're trying to do. I think the front panels is useful sometimes, but in many cases that I face, I would say 90% I care more about the Block Diagram and the wire values found within it. Or worst yet ... and I feel ashamed and dirty I use one button dialog to see where my code actually went ... in tricky debug sessions when dealing with reentrancy and AF. We have multiple use cases, and many of us ( myself included ) are dinosaurs. We are used to LabVIEW's quirks and do stuff our own way. From NI's perspective I totally understand how it is hard to get feedback on what the IDE should do, as I think that where you have 2 CLAs you have 3 opinions. I was really looking forward to NXG to take a clean break and trying to take a crack at the making something that will allow me to use G in a modern way. I get it it wasn't working and had to be stopped, lets just hope that the stuff NI has learned during development of NXG can be somewhat applied to current gen as it has fallen behind as an IDE quite badly.

Thanks for that, this is definitely worth investigating on my end. I will give it a go. I managed to find a download link to this utility on ni.com. I have not tried yet, but I think it might be included in the SSP package. Looks like this could potentially work for my use case of Prototype on NI - FPGA on a SBRio and deploy on a ZynQ for mass production. This is not quite what I was asking for but if it works well it could be a viable option. Thanks!

The future is Python for many of the applications, it is easy to get in to for newcomers to programming, works great has a strong package management system and large community, and can be applied to virtually any OS you can think of, as well as it can be even used to program GPUs if you are so inclined. The huge advantage of using G and LabVIEW is that paired with NI Hardware, in the hands of someone skilled with LV you can bang out a solid prototype of a product or a Test and Measurement system so fast it will make people's heads spin. NI hardware is absolutely top notch for High End use cases or rapid prototyping, complex one offs , scientific use or complicated Test and Measurement end of line test space. However in the IoT there is strong competition for the NI SB RIO line up, for a SB RIO you will pay 1500 US. There are so may cheap programmable & capable pieces of hardware, such as Jetson Nano (ARM7+NVidia GPU for vision) or Raspberry PI (ARM7 1.4 GHz with 8GB RAM) or even Asus Tinker Board ... which will serve so many purposes and have onboard GPIO and can be purchased for 50-60 bucks ... that in that space Python paired with Linux knowledge is really making headway. And if you want to go with ZynQ from Xlinix you can get a board with FPGA ~300 Bucks, which is basically the same HW as SB RIO, all you have to do is use different software tools. If NI would consider unlocking the ability use NI FPGA with the ability to deploy to non NI Hardware ... I think this is where G absolutely would take off like wildfire and be used on millions of IoT devices everywhere in the world that are powered by and ARM7 + FPGA module... but as it stands now if you use NI FPGA you must deploy on a target you've purchased from NI. I'll really be a stickler but if we're talking about the programming language we should talk of G. LabVIEW the IDE. Never say never, I am not aware of any other graphical programming language which could be used for general purpose programing and is as complete as G. If you have come across something interesting I would like to look at it, but I feel that it would be at best an academic project, which I would not use in production code.

I agree with Shaun that lack of support for other platforms is fatal. Although I remember speaking with NI folks early on and I think the idea as far as I understood it during one of the CLA summits that the IDE of NXG was going to be Windows only, but I do think they were thinking of having runtimes capable of running on different OSes. However as far as it stands right now for NXG 5.0 I don't see any indication of the possibility of running NXG code on a platform other than Windows... ( I'm getting' old I might not be remembering stuff correctly anymore ) So I think the plan was there to be able to deploy on different platforms and OS flavors early on, but with all the other things not going right I think they never got to it and it kept getting pushed down the backlog.

Well my 2 Cents. This is bad for the future of the G programming language in my opinion. I've not used NXG in production as it was never ready enough and it did feel like a constant prototype. However the overall experience with working with it as an IDE at least in the capacity I've used was a positive one. I've used it for the European CLA summit presentation back in 2019 and exercised mainly the C/C++ interface to connect Current Gen and NXG with Zero MQ. The changes in NXG in that area, in my estimation, have been logical and it was really easy to work with and made a lot of sense. Killing off NXG, which was constantly not ready for production makes sense after all these years. The truth is it was not possible to use it on a real project in a significant way. However this is a huge effort is now basically flushed down the toilet, and I'm quite pessimistic about redirecting the effort and reusing the components developed as part of NXG and integrating them into the LabVIEW current gen. I love graphical programming, and it is a very refreshing way of thinking about code, but current gen is clunky and 30 years old. And it is very painful to use for small team development (3-5 members) and is completely not suitable for large teams (10+ developers). In reality my biggest concern is that the G language and the IDE of LabVIEW are joined at the hip and that is I think the crux of the issue. In order for G to survive as a viable option for the future it would need to be de-coupled from the old IDE of LabVIEW. But it seems to me like now they will be entangled together till the bitter end... until the user base of LabVIEW retires, and no new cutting edge projects will be created in G, not because G sucks but because LabVIEW IDE is holding it back. Cheers, Maciej