Inheriting a codebase - the way forward?

[armmic]

Hi

I have recently inherited quite a large codebase from a former colleague. On inspection it is going to be a beast to maintain. I have many (10's) of slightly different machines to look after - all of which have a slightly different version of the same code on.

There are lots of rookie mistakes - not using projects, no enums, stacked sequences,etc. You name them, I've got them.

I also have several different versions of LabVIEW running in the factory from LabVIEW 6 up to LabVIEW 2014.

My first couple of questions regarding this mess are:

Is there any risk in taking the working code from a machine and bringing it into a project? I'm thinking that once it's in a project it may make it easier to maintain (and work out how it all works!)

What are the risks involved in migrating code from older versions of LabVIEW to more recent? Should I even bother with migrating LabVIEW 6 code or just let sleeping dogs lie?

BTW: The LabVIEW 6 application isgoing to require a bit of an overhaul soon anyway as we have a new product out which the old code is not quite compatible with...

Thanks!

Mike

[GerdW · Accepted solution]

Hi armmic,

first step: setup a SCC system!

After checking in all "projects" you can try to refactor the code…

I also recommend to build up a common "libs" project (or use the user.lib) to hold all code, that is common between those "projects"/"machines"…

If possible you should use the same LabVIEW version for all machines. Upgrading from LV6 might be a hassle when it comes to replacing TraditionalDAQ with DAQmx code. (Some other toolkits/APIs changed as well.)

[crabman · Accepted solution]

Hi,

as GerdW already said sourcecode control is an absolue muste have. So if there is none implemented yet, do not touch any code...

But from what I read from your post you have LabVIEW (in different versions) running directly on the machines? Meaning no .exe files but VIs?

That can be a real problem, because once you changed the installed LabVIEW Version on a machine you might never run the old code again. Re-installation of LabVIEW and drivers like from the stone age is always problematic.

So the very first step I would recommend is creating backups in form of complete harddrive clones from all our machines. That way you have at least a working backup somwhere in the case of complete installation- and driver chaos.

[crossrulz · Accepted solution]

---

@armmic wrote:

Is there any risk in taking the working code from a machine and bringing it into a project? I'm thinking that once it's in a project it may make it easier to maintain (and work out how it all works!)

---

Very minor risk.  The only real risk I can immediately think of is you will find linking/conflict errors.  But those should probably be fixed anyways.  When I have inherited "old" projects, putting it in a LabVIEW Project is the first thing I do.

---

@armmic wrote:

What are the risks involved in migrating code from older versions of LabVIEW to more recent? Should I even bother with migrating LabVIEW 6 code or just let sleeping dogs lie?

---

Most of the risk from migrating from older versions of LabVIEW comes from the drivers.  This is especially true if your code used the older Traditional DAQ (which has been fully replaced by DAQmx).

As far as your LabVIEW 6 application, I would just plan on fully replacing it.  Depending on what the code is doing, you might want to consider using TestStand (test sequencing) or Veristand (Hardware in the Loop).

[PointOnePa]

>Is there any risk in taking the working code from a machine and bringing it into a project?

  I've done this multiple times with different versions and that only problems I can recall is references having to do with hard links and references in the software, which are usually easy to find.

You state: "I have many (10's) of slightly different machines".  I would start by making a list of what you have in terms of hardware including DaqMX, Windows Operating Systems, and LabVIEW versions.  Then I would check for compatability.  You may end up spltting the code base for old versus new, since not all versions are supported by updated the software.

Check out the following for DAQmx compatibility issues with LabVIEW versions.  I've been bitten by this multiple times. 

https://www.ni.com/en/support/documentation/compatibility/16/ni-daqmx-and-labview-compatibility.html

Also, it's relalistic to think that you won't have the budget to update all of your hardware and might be stuck running old versions of Windows (XP...etc). It happens.  So if you are stuck with old Windows XP machines, make sure you check on the LabVIEW version compatibility.

https://www.ni.com/en/support/documentation/compatibility/17/labview-and-microsoft-windows-compatibi...

If you have an infinite budget, throw out the above comments and just update all the hardware and software to the same version.  Then you'll have a single code base.

[Bob_Schor]

---

@PointOnePa wrote:

If you have an infinite budget, throw out the above comments and just update all the hardware and software to the same version.  Then you'll have a single code base.

---

I think that the "infinite budget" approach is to try to maintain 10 different versions!  Developer Time and Agony is also Money!

Computers are (relatively) inexpensive.  Inventory your DAQ hardware and see what is compatible with "Modern LabVIEW" (meaning LabVIEW 2016 and later -- given NI's "5-year-obsolescent" principle, you want to start as "fresh" as feasible).

Find a Version Control System and use it!  [I've been very happy with Subversion for more than a Decade, and it has definitely saved time and hair (that hasn't been pulled out in frustration).

Take the latest working version and bring it into a LabVIEW Project.  Commit the Project, and start refactoring it.  It may help to do something really "Old School" -- write Documentation describing What the Project is supposed to do.  Don't worry about the "How" at the present time -- if you've got code from LabVIEW 6, you might not have "Modern LabVIEW Best Practices" and "Design Principles" (such as Queued Message Handlers, Producer/Consumer Design Patterns, multiple interacting parallel loops, LVOOP, etc.) in mind or in your existing code base.  But having a reasonably-complete "Top Level Design" before you start coding can be a real time- and effort-saver ("Been There, Done That", but from LabVIEW 7.0).

Find a colleague.  Even if you end up doing this largely yourself, having someone to discuss Design and help when the code doesn't work ("Is this Wire supposed to be attached to something?") really helps.  If you are at a University, don't overlook good students ...

Bob Schor

[paul_cardinale]

Too many times I've salvaged someone else's crappy code.  These days when I come across stuff like that, I throw it in the trash and start over.

Usually trying to turn a sow's ear into a silver spoon takes more effort, than making the spoon from scratch.

[RTSLVU]

I am with Paul here, I have never inherited any code worth keeping.

I am not saying I am the best LabVIEW programmer in our company but I am certainly not the worst!

[armmic]

Yes, SCC has got to be top of my list. In our R&D department we are using GitLab for firmware source code - I've never used it myself (I've used Tortoise SVN in the past). Any experience of GitLab with LabVIEW? - Pros and Cons etc?

Common libs - I'm going to have to spend a lot of time going through all of the code that is the 'same' to check if there have been any upgrades. Also there is no record of what has been upgraded - I don't want to accidently downgrade the code or reintroduce old bugs...

Regarding the LabVIEW versions - we are running the Deployment version of LabVIEW in the factory, with the Main.vi on the desktop set to automatically run. To allintents and purposes it looks like an exe, but obviously there's a risk with the source code being exposed...

Thanks for your help

[wiebe@CARYA]

---

@armmic wrote:

There are lots of rookie mistakes - not using projects, 

---

If it was made in LabVIEW 6, then there simply where no projects... Can blame that on him\her!