08-27-2014 04:49 PM
Hello LabVIEW gurus,
I am just given a few software tools to add functionality and rewrite, each of which is a big spaghetti mess and each tool has 100+ vis all sphagetti, these tools control a very complex machine talking via seria, parallel, ethernet, 485 etc. and there is barely any documentation of the logic or the implemetation of the source code / what the subvis do.
what would be my best approach to understand this mess and recreate it in a structured way faster. it has lot of old sequence structures and just plain bad style of programming.
any help is highly appreciated
Thanks all
08-27-2014 05:56 PM
Run for your life...
Believe it or not, I have found the Block Diagram Cleanup often helps in these situations. Tends to clean up a lot of the weird wiring and make things more linear looking.
Other than that, I find it best to just cleanup as you go while you study the code. Make sure you are using source code control, just in case you break something. Always test before you touch any code and test afterwards to make sure you didn't break anything. Add in the documentation based on your understanding. Put in questions for things you don't understand.
08-27-2014 06:22 PM
Run for your life...
is good advice!
Not only use source code control but make about three copies of the original (*mostly working*) code and move at least two of those off line in a read-only format. Then do not change any of those copies but make another copy to work on.
Figuring out what the code does is the most important part of what you will be doing. Not just what is is supposed to do but what it actually does. I had one of those messes once where I found several bugs in the original code which made it do things which the users said it should not do - but they were so sure that it worked the way they wanted that fixing the bugs made them unhappy. If the code says that 2 + 2 = 3.8, but the devices coming off the test rig satisfy marketing and the customers, then you must be very, very careful about correcting the math.
Lynn
08-27-2014 08:43 PM
Sometimes, I like to use the hierarchical view of the project. It helps about the understanding. Sometimes...
That's just an advice.
08-27-2014 09:10 PM - edited 08-27-2014 09:16 PM
OK, you've been practicing this craft for at least 6 years I won't treat you as a newbie.
The last solution I delivered was "%75 functioning" when I inherited it. It was good code! "Good" With some nifty custom animated UI controls that I would not like to duplicate (Yet, meaningless to the user! the point of the system was to AUTOMATE it so the user could walk away and do something productive) Less than %1 of that code was refactored into the deliverables.
What it had was six parallel loops- it needed 6 QMHs and a bunch of plugins (Actors) keyed to seven dynamic events.
Get the "User Story" Users often want something much simpler than what you want to deliver
If you have a Tab Control on the main GUI- you probably are wrong (I HATE Tabs- they confuse users and hide the subject task at hand)
If you need "Engineering Support" there is no reason a project MUST contain only one app build spec
Draw up the sections of code that do not depend on each other.
Figure out what would be the best method of communicating between those section (And WHO is in charge) The Synchronization palatte could be a good friend here.
USE established design patterns! They WORK.
If you still feel like running away, ask for help from a local Certified LabVIEW Consultant... They can be found on the partner locator.
08-28-2014 05:15 AM
08-28-2014 06:24 AM - edited 08-28-2014 06:25 AM
Another thing to keep in mind, if you even begin to consider rewriting the entire thing, is that there are probably a bunch of corner-case issues that were already solved. They'll look like pieces of code that don't belong, and they'll laugh at you later as you scratch your head wondering why your CAN device occasionally transmitts what appear to be malformed messages with an ArbID of zero and you handle it the same way Mr. Spaghetti did. That reminds me, I need to go comment some code...
08-28-2014 06:39 AM
If your task is only to ADD things, you might be interested in Steve's recommendation here.
Norbert
08-28-2014 08:23 PM - edited 08-28-2014 08:50 PM
And Do not forget about using the VI Analyzer TK! It can reveal several obvious sources to clarify code that "Stinks" A lot of skull sweat went into that framework and it has signifigant value!
@Norbert_B wrote:
If your task is only to ADD things, you might be interested in Steve's recommendation here.
Norbert
(Inside joke ahead)
Ah, That explains the TDMS File Viewer!
09-02-2014 07:43 PM
thanks all,
i will follow your suggestions