Neil Pate

OK, so deleting the branch on the remote only deletes it from being used in future, it still exists in the past and can be visualised? Sorry I misunderstood and thought that git did magic to actually remove the branch in the past (which would be a bad thing). I know about rebase but have never thought to use it.

I still don't really get this. I want to see the branches when I look in the past. If the branch on the remote is deleted then I lose a bit of the story of how the code got to that state don't I?

It's been a while but when using the NI Modbus library I found there was some weirdness regarding what the base of the system is. This might just be my misunderstanding of Modbus but for example to read a holding register that was at address 40001 I would actually need to use the Read Holding Register VI with an address of 1 (or 0). This snippet works fine for reading multiple registers, but see the VI I had to write on the left to do the register address translation.

So I am pretty new to GitHub and pull requests (I still am not sure I 100% understand the concept of local and remotes having totally different branches either!) But what is this all about? I have done a bit of digging and it seems the current best practice is indeed to delete the branch when it is no longer needed. This is also a totally strange concept to me. I presume the branch they are talking about here is the remote branch? Confused...

NI: "Engineer Ambitiously" "Change some fonts and colours, that will shut up the filthy unwashed masses who are not Fortune 500 companies"

So I am not a Modbus expert, but have definitely written information to a PLC in the past. As far as I know you cannot write to input registers, I presume you can write to output registers (are they called coils?). I don't have the toolkits installed on my PC right now so I cannot check. This code below works fine for setting Holding Registers. Have you tried writing to the Holding Registers? I

I do agree with you, but must confess that at least once in my dark past I have coloured a block diagram. It was a VI I hated and wanted to get rid of so I coloured the background an awful red colour to remind me every time I opened it.

I cannot recall doing this with a LOGO! but have done it quite a bit with plain old S7s. The Modbus module (now open source) works just fine. What difficulties are you having?

Just to chip in here, I recall hearing that NI is going to be moving away from the regular biannual releases of LabVIEW. I cannot remember where I heard or read this though.

Have you tried to mass compile?

Nice article also, part 1 of 7! https://arstechnica.com/science/2021/01/the-curious-observers-guide-to-quantum-mechanics/

Are you sure you burned the correct amount of sage during the incantation?

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

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?

Another option is Alice. It combines a 3D environment with a language quite similar to some of the others mentioned. It can be fun for younger kids as they can ignore the programming bit and just construct a 3D scene with some props quite easily.

Dear Santa NI I am now in my 40s with youngish kids, so despite the fact that all I got for Christmas this year was a Pickle Rick cushion I am not actually complaining. However, I would like to get my order in to the Elves as early as possible. This is my wishlist, in no particular order. I expect this list will not be to everyone's taste, this is ok, this is just my opinion. Make LabVIEW free forever. The war is over, Python has won. If you want to be relevant in 5 to 10 years you need to embrace this. The community edition is a great start but is is probably not enough. Note: I accept it might be necessary to charge for FPGA stuff where I presume you license Xilinx tools. NI is and has always been a hardware company. Make all toolkits free. See the above point. Remove all third party licensing stuff. Nobody makes any money from this anyway. Encourage completely open sharing of code and lead by example. Take all the software engineering knowledge gained during the NXG experiment and start a deep refactor of the current gen IDE. Small changes here please though... we should not have to wait 10 years. Listen to the feedback of your most passionate users during this refactor. NXG failed because you ignored us and just assumed we would consume whatever was placed in front of us. I am talking about the people like those reading this post on Christmas day and their spare time because they are so deeply committed to LabVIEW My eyes are not what they used to be, so please bring in the NXG style vector graphic support so I can adjust the zoom of my block diagram and front panel to suit accordingly As part of the deep refactor, the run-time GUI needs to be modernised. We need proper support for resizable GUIs that react sensible to high DPI environments. Bring the best bits of NXG over to current gen. For example the dockable properties pane. (Sorry not much else comes to mind) 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. Get rid of the 32-bit version and make RT 64-bit compatible. You are a decade overdue here. Add unicode support. I have only needed this a few times, but it is mandatory for a multicultural language in 2021 and going forward Port the Web Module to Current Gen. All the news I have heard is that the Web Module is going to become a standalone product. Please bring this into Current Gen. This has so much potential. Stop adding features for a few years. Spend the engineering effort polishing. Fix the random weirdness we get when deploying to RT Open source as many toolkits as you can. Move the Vision toolkit over to OpenCV and make it open source Sell your hardware a bit cheaper. We love your hardware and the integration with LabVIEW but when you are a big multiple more expensive than a competitor it is very hard to justify the cost. Allow people to source NI hardware through whatever channel makes most sense to them. Currently the rules on hardware purchasing across regions are ridiculous. Bring ni.com into the 21st century. The website is a dinosaur and makes me sad whenever I have to use it Re-engage with universities to inspire the next generation of young engineers and makers. This will be much easier if the price is zero Re-engage with the community of your most passionate supporters. Lately it has felt like there is a black hole when communicating with you Engineer ambitiously? What does this even mean? The people using your products are doing their best, please don't patronise us with this slogan. 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 Remove all hurdles to hand-editing of these files (no more pointless hashes for "protection" of .lvlibs and VIs etc) Openly publish the file formats to allow advanced users to make toolkits. We have some seriously skilled users here who already know how to edit the binary versions! Embrace this, it can only help you. Introduce some kind of virtualenv ala Python. i.e. allow libraries and toolkits to be installed on a per-project basis. (I think this is something JKI are investigating with their new Project Dragon thing) For the love of all that is holy do not integrate Git deeply into LabVIEW. Nobody wants to be locked into someone else's choice of SCC. (That said, I do think everyone should use Git anyway, this is another war that has been won). That is about it for now. All I want is for you guys to succeed so my career of nearly 20 years does not need to be flushed down the toilet like 2020. Love you Neil (Edited: added a few more bullets)

Ditto to what Rolf said.

Sounds... Complicated. I honestly think OOP designs like this are generally more trouble than the return you get from it.

Removal of Run Continuously. Vomit. I lost my voice trying to explain how removing this is a totally unnecessary modification.

Interesting question. I would say yes due to the fundamental nature of OOP but what worries me is the natural next step then is to say that The Actor Framework is also something a CLA should have applied knowledge of, and that would not be sensible.

But I am actually grateful for necro-ing this thread as I had not seen it first time and was interested to read it.

I think you might be in the minority here. How about I offer you shared variables instead?

At this point we should be looking to remove things from Core LabVIEW, not adding them. LabVIEW already carries way too much baggage. I am strongly against NI trying to push YAAF (yet another actor framework) onto us.

Conversely, it feels like NXG was built by devs not actually intimately familiar with LabVIEW.

Ah Lena, bet you never expected such fame. A little bit of light reading here.