LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

IS UPDATING THIS CODE WORTH THE EFFORT OR SHOULD I START FROM SCRATCH?

I was asked to get familiar with this program which is used to conduct endurance testing on 3 Aerospace Hydraulic Components.

 

Looking at the Code, it seems very hard to follow, little comments, little documentations on code or paper. Looking at the code on just the Data Acquisition I'm not sure why or how it works or has enough resources.

 

The program is pretty big and there is quite a bit of data being collected. The Program was run to get a few steps of the test completed but the engineer/programmer had to always go back and make adjustments.

 

We must run it again in a few months and I'm sure there will be glitches. Please take a look at some code snippets.

 

DO YOU THINK I SHOULD ASK FOR ENOUGH TIME TO START OVER OR SHOULD I JUST TRY TO GET BY WITH THIS CODE?

 

I'm not even sure if with the way the code was made, if the data obtained is really accurate.

 

 

Thanks for whatever advice you can offer.

 

JC

JCollado
Download All
0 Kudos
Message 1 of 12
(3,291 Views)

I would replace it. All of those different tasks for analog and digital seem pretty wasteful. I would have a single task for each resource (ai, ao, di, do) and read multiple channels at once. Even if you stuck with a 1Sample read/write, I'd bet you would see an improvement in speed. You'd have far fewer DAQmx functions on the block diagram as well - making it more readable.

Message 2 of 12
(3,254 Views)

Re-writing will take longer, but always think of how many more hours it will take to maintain/modify poorly written code.

PaulG.

LabVIEW versions 5.0 - 2020

“All programmers are optimists”
― Frederick P. Brooks Jr.
Message 3 of 12
(3,246 Views)

First of all, I see a bunch of race conditions in there (writing to terminals and reading from local variables).  Those need to be cleaned up or you will always be a cycle behine.

 

All of those DAQmx channels really need grouped into tasks.  All of the digital inputs could be a task.  Same for all of the Analog Inputs.  Ditto for the Digital Outputs.

 

That Stacked Sequence Structure worries me, especially since I see local variables in there.  Looks like someone needs to learn a state machine.

 

Yes, there is a lot that could be improved.  But at what cost?  If it actually works, then it isn't worth updating until you hit a major bug.  At that point, I would push for a rewrite.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 12
(3,239 Views)

 

Thank you gusy for the quick replies.

 

Yes, teh guy who wrote it is a brilliant Engineer but I very little Labview Skills (and this is coming from me, not an expert either).

 

I will suggest we run it and try to get by with minor adjustments.

 

If it needs to keep going for a long time and there are many issues, then I will suggest we re-write it.

 

It is a bit scary to run so many euipments with High pressure Hydraulics using this program though.

 

Thank you all

 

 

JCollado
0 Kudos
Message 5 of 12
(3,213 Views)

That code really shouldn't take long to re-write using a proper design pattern and a *.lvproj to organize the code and maintain the DAQmx Tasks.  Just getting the Tasks into a lvproj will save you the hours it takes to re-vamp the first time you need to check out a system hardware issue.


"Should be" isn't "Is" -Jay
Message 6 of 12
(3,191 Views)

I'd re-write it.  But the answer actually depends on YOUR labview skills and HOW MUCH you need change.  If you are relatively new to LabVIEW, then you'll be investing a lot of time to start from scratch.  And if you have only a few simple changes, then you might want just try and hack them out.

http://www.medicollector.com
Message 7 of 12
(3,172 Views)

JC,

 

I would plan on replacing as soon as practical. What is practical depends on part (big part) on what the boss says.

 

If you decide or are forced to run it as is, then do several things:

1. Document that the existing program is poorly written, and while it may work, even tiny "fixes" have the potential to break it or to introduce errors. There is no good way to predict when this might happen.  Managers and bosses do not like surprises.  Keep them informed, even if it means telling them something they do not want to hear. Better they know up front than finding out when the production line shuts down!

2. Document everything you can about what it does or is supposed to do, particularly from the user's point of view. It is amazing how many times someone says, "This program works fine," and then they add, "...except..." Record those exceptions even if you do not know why they occur or how to fix them. Also record any known bugs, errors, and things the user finds uncomfortable or awkward to use.    Include any historical documents related to the development of the existing program.  These documents become a basis for creating a performance specification for the new program when you write it.

2.A. Make notes about anything you identify which you may want to change, replace, verify that it works the way you think it does, and so on. These notes may be helpful when you do start the re-write.

3. Make several backups and move at least one to CD/DVD and off site. If you break something while trying to fix soemthing else, you need a simple way to go back.

4. Some guidelines which should trigger a rewrite as opposed to a "fix:"

  A. The fix requires running wires all over the block diagram.

  B. A new feature is requested. The way the original code is put together even adding a channel qualifies as a new feature. If the tasks were combined as has been suggested, then adding a channel might be as simple as changing a constant.

  C. All the code for the fix will not fit into one or two subVIs. Always implement fixes as subVIs, if possible. It makes it much easier to go back if the fix breaks something else. If it will take multiple subVIs or it gets very complicated, the risk of making things worse gets much larger.

  D. You cannot think of an easy way to fix the problem. If the fix is not fairly easy and fairly obvious, it probably is a strong indication that a different program architecture is appropriate - and that is an indication for the re-write.

 

Good luck.

 

Lynn

Message 8 of 12
(3,112 Views)

This is worth a read if you're deciding whether or not to modify existing (possibly bad code) versus rewriting from scratch.

http://www.joelonsoftware.com/articles/fog0000000069.html

 

At my work, I have inherited some code (particularly a laptop that runs test software in the LV development environment - huge amounts of nested case structures, sequence structures, dead code, terrible UI etc.) and it just isn't worth rewriting the whole thing - it works, the team that use it are happy with it and they know it works. In other software, I have refactored just parts of the code when I wasn't happy with it and I have a project that when I have time, I'd like to 'do it again, but better'.


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 9 of 12
(2,921 Views)

That code should be fairly easy to restructure/clean up to a decent standard. As already mentioned, make arrays of all AI-channels, add to a task in a loop and bundle all tasks to a cluster that runs through the program in a shift register. That way all those digital reads will be 1 read boolean array, e.g.

 

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 10 of 12
(2,898 Views)