Porting LabVIEW code to another language

[infinitenothing]

Has anyone gone through the experience of rewriting your LabVIEW code into a different programming language? I'm wondering if it was a total rewrite or if you went line by line translating it to a new language? After the effort was over, was the end result still buggy? Did it take it a while to get it back to its former reliability?

For people that haven't gone through that—what's your game plan if the time comes when you have to move your code over?

Related thread explaining some of the context of this question:

 

[ShaunR]

1 hour ago, infinitenothing said:

I'm wondering if it was a total rewrite or if you went line by line translating it to a new language?

Don't you mean "wire by wire"? 

Generally, VI's are functions so you could write the same functions but the contents would be completely different. Many functions just wouldn't be relevant because of the way LabVIEW works - especially if they are to control the UI. Then it also depends on what you are going to write the new code in. Delphi UI's are, for example, event driven so you are in a completely different paradigm. If you have architected your program then you can transfer the architecture but you are still moving to a different paradigm (from data-flow). A lot of the LabVIEW support (drivers etc) come with other language bindings, so the really hard stuff such as DAQ and VISA etc wouldn't be too bad.

Personally, I would do (and have done) a complete rewrite and change all the things I didn't like about the old program-if push came to shove. Saying that, though, you would be better off replacing parts, piecemeal, with DLL's until there is no LabVIEW left. I was in a position where I could do a complete rewrite (ah, Waterfall development  ) At least then you can reuse the DLL's at the very least. If you also create DLL's from LabVIEW code, you can integrate them into the new, non LabVIEW  software and then replace them later with non-LabVIEW DLLs.

Boy, you've had a huge black pill suppository, haven't you  

[infinitenothing]

FYI, in my particular case there's no UI. It's all headless RT code targeting a ZYNQ [sb,c]RIO. There's a few TCP loops, some logic for homing motors, some RS232 commands out, a bit of data processing/analysis, etc. I can't go out to a dll because my main roadblock is the run time engine. If I can get the run time engine working then I'll just keep everything as LabVIEW.

Speaking of data flow, do you think some languages are better targets than others? The options I'm considering Java and Python mostly because I want memory management to stay out of my way as much as possible.

Re: black pill. There are many other things I'd prefer to spend my time on.

Edited April 19, 2022 by infinitenothing

[JKSH]

6 hours ago, infinitenothing said:

It's all headless RT code targeting a ZYNQ [sb,c]RIO.... If I can get the run time engine working then I'll just keep everything as LabVIEW.

NI Linux RT is just another Linux distro. If you can install Linux on your device, you can probably install NI Linux RT which comes with the LabVIEW runtime. I'm not sure what the licensing implications are. You probably won't get NI hardware driver support, however.

The Zynq FPGA is a completely different beast.

 

6 hours ago, infinitenothing said:

Speaking of data flow, do you think some languages are better targets than others?

The only other widespread dataflow language in industry (that I know of) is Simulink, so...

The best language is one that you are experienced and competent in. The next best language is one that you have resources and drive to learn.

Edited April 20, 2022 by JKSH

[Rolf Kalbermatter]

6 hours ago, JKSH said:

NI Linux RT is just another Linux distro. If you can install Linux on your device, you can probably install NI Linux RT which comes with the LabVIEW runtime. I'm not sure what the licensing implications are. You probably won't get NI hardware driver support, however.

NI Linux RT is the NI version of the Linux kernel and as such is of course GNU licensed. You can grab the sources and compile it yourself and install it on whatever hardware you want!

BUT!!!!! That is just the Linux kernel. The LabVIEW runtime engine, NI-VISA, NI-4882, NI-PAL, NI-DAQmx, NI-IMAQ, NI-RIO and many more NI-somethings all are fully and completely copyrighted by NI and you do not have the right to copy them around as you wish. While drivers like NI-VISA and NI-DAQmx are generally also available for standard desktop Linux systems and from there can be installed on your own x86 based (embedded) hardware, this is an entirely different beast for the LabVIEW real-time runtime engine and all its dependencies. For this you would need to get an explicit license from NI or risk to get their lawyers chase your butt. Also the ARM compiled NI-drivers are also NOT part of a standard driver installer but only come with the LabVIEW realtime runtime installer or the Community Edition target firmware Installer for Raspberry Pi and Beaglebone Black. The LabVIEW realtime runtime is ONLY licensed to you according to the respective license that comes with those two. For the LabVIEW realtime runtime installer, that is explicitly only licensed to run on NI hardware and the Community Edition comes with the explicit non-commercial use only restriction.

So until NI decides to sell an actual NI Linux realtime runtime license as they did for the NI Pharlap runtime license you are not only skating on thin ice by using those components on your own hardware but fully and truly illegal. However the support burdon for such a license is most likely the main reason they haven't done anything more than saying that they are monitoring the market and will decide when they feel it is useful. That was 8 years ago their standard response, and with the current state of affairs, chances that they will release something like that are actually quite a bit smaller than back then.

Edited April 20, 2022 by Rolf Kalbermatter

[JKSH]

6 hours ago, Rolf Kalbermatter said:

So until NI decides to sell an actual NI Linux realtime runtime license

Ain't this it? https://uk.farnell.com/ni/777849-35/labview-real-time-deployment-license/dp/3701592

[hooovahh]

36 minutes ago, JKSH said:

Ain't this it? https://uk.farnell.com/ni/777849-35/labview-real-time-deployment-license/dp/3701592

I can't tell honestly if that is the same thing or not.  I looked up the part number and it said it is a "LabVIEW Real-Time Deployment License for PC", but on the page talking about converting a Desktop PC to an RT target, it states "Note: NI is not currently planning on supporting conversion of desktop PCs to NI Linux Real-Time targets. Conversion of desktop PCs to Phar Lap ETS targets is supported."  And this was last updated 5 months ago.

But on a page talking about converting a desktop to RT, it lists Option 2 as using the license you mentioned.

Edit: Now that I look at these I think the original page you linked to at Farnell is incorrect.  I think that is a normal RT non-Linux variant license and the page is wrong based on the product number they listed.

[LogMAN]

On 4/19/2022 at 6:38 PM, infinitenothing said:

Has anyone gone through the experience of rewriting your LabVIEW code into a different programming language?

I had to do that once. Moved from LV to C++

On 4/19/2022 at 6:38 PM, infinitenothing said:

I'm wondering if it was a total rewrite or if you went line by line translating it to a new language?

A translation doesn't make sense as many concepts don't transfer well between languages, so it was rewritten from scratch.

It's actually funny to see how simple things become complex and vice versa as you try to map your architecture to a different language.

On 4/19/2022 at 6:38 PM, infinitenothing said:

After the effort was over, was the end result still buggy?

I assume by "done" you mean feature parity.

We approached it as any other software project. First build a MVP and then iterate with new features and bug fixes. We also provided an upgrade path to ensure that customers could upgrade seamlessly (with minimal changes) and made feature parity a high priority. The end result is naturally less buggy as we didn't bother to rewrite bugs 😉

On 4/19/2022 at 6:38 PM, infinitenothing said:

Did it take it a while to get it back to its former reliability?

It certainly took a while to get all features implemented but reliability was never a concern. We made our test cases as thorough as possible to ensure that it performs at least as well as the previous software. There is no point in rewriting software if the end result is the same (or even worse) than its predecessor. That would just be a waste of money and developer time.

[Rolf Kalbermatter]

7 hours ago, JKSH said:

Ain't this it? https://uk.farnell.com/ni/777849-35/labview-real-time-deployment-license/dp/3701592

According to this page, the part number 777849-35 is the single seat LabVIEW Pharlap ETS deployment license. Never mind the strange currency in those pics which seems to be Indian Rupias.

And the online download page is here, when you select the Debug/Deploy option. The download page is less clear about what exactly it is, and the order number shown is rather 777845-35, but I'm pretty sure it is really the Pharlap ETS license and the information on the Farnell site seems therefore bogus. Considering that NI discontinued support of Pharlap ETS for all options already in the latest LabVIEW version, it's amazing that you still can buy it.

[JKSH]

10 hours ago, hooovahh said:

Now that I look at these I think the original page you linked to at Farnell is incorrect.  I think that is a normal RT non-Linux variant license and the page is wrong based on the product number they listed.

3 hours ago, Rolf Kalbermatter said:

I'm pretty sure it is really the Pharlap ETS license and the information on the Farnell site seems therefore bogus. Considering that NI discontinued support of Pharlap ETS for all options already in the latest LabVIEW version, it's amazing that you still can buy it.

That's rather worrying then, given that Farnell is now an "Authorized Distributor" for NI.

[Rolf Kalbermatter]

7 hours ago, JKSH said:

That's rather worrying then, given that Farnell is now an "Authorized Distributor" for NI.

I used to put a lot of trust into what was on the Farnell site in respect to the product description. But since Corona hit or maybe even a bit earlier, the information on the Farnell site for products has gone downhill. Not only doesn't the text always match the actual product but also the available datasheets for a product listing are either only slightly related and sometimes outright wrong. I used to report such inconsistencies but refuse to be their unpaid website reviewer!

Edited April 21, 2022 by Rolf Kalbermatter

[Lipko]

Whenever I had to rewrite stuff and restarted from scratch, the result (GUI, bugs, code quality) was much better. Okay, I'm learning continuously and I jump into real projects when I have the absolute minimum required language knowledge, so even in the course of one project my coding style can change a lot, so I have some really bad code mixing methods like crazy (LV small data storage example in non-speed-critical aplications: local varaibles (I dropped that very early)->shift registers->hidden indicators).

In my uneducated opinion the biggest obstackle of making clean code and fine architecture (thus less bugs, better improvability) is that it's impossible to fully flesh out the specifications when starting a new project (and refractoring can be a real pain).
On the other hand if you port (especially if you are also an active user of the program), then you have a solid specification and a working "prototype" (the original project) mapped out to the last detail. Of course, you have to be ready with a very detailed test plan.

[LogMAN]

43 minutes ago, Lipko said:

In my uneducated opinion the biggest obstackle of making clean code and fine architecture (thus less bugs, better improvability) is that it's impossible to fully flesh out the specifications when starting a new project (and refractoring can be a real pain).
On the other hand if you port (especially if you are also an active user of the program), then you have a solid specification and a working "prototype" (the original project) mapped out to the last detail. Of course, you have to be ready with a very detailed test plan.

Even without porting to a different language, a small prototype is a good idea if you aren't sure about your architecture. That way you can test your ideas early in the project and refine it before you begin the actual project. Just don't forget to throw away the prototype before it gets too useful 😉

[ShaunR]

27 minutes ago, LogMAN said:

Just don't forget to throw away the prototype before it gets too useful

A prototype is just a program before you up issue it to version 1.0.0. Either that or it becomes a test harness. Why would you throw away anything that's useful? 

All the examples in ECL started as prototypes and they now double as black-box regression tests.

Edited April 21, 2022 by ShaunR

[LogMAN]

19 minutes ago, ShaunR said:

A prototype is just a program before you up issue it to version 1.0.0. Either that or it becomes a test harness. Why would you throw away anything that's useful? 

Good question. There are different kinds of prototypes that serve different purposes.

The one I'm referring to is a throwaway prototype. It serves as a training ground to try out a new architecture and/or refine requirements early in the process. The entire point of this kind of prototype is to build it fast, learn from it, then throw it away and build a better version with the knowledge gained.