Need help with cleaning up a user interface

[Rivetm]

Hello everyone, I am new to Labview, however I do have core 1 and core2 undermy belt. I have inherited some code that I am suppose to clean up, and could use some suggestions. The code seems to abuse the use of variables and flat sequence structures. I would like to limit as much as possible the use of variables and flat sequence structures; also hook the controls up an event structure.Take a look at this code please and let me know what you would suggest.

[EricC.]

Hello

a look quickly your code and i have some sugestion

be careful on coercicion dot.

You set data in variable but the have a different datatype of the variable (eg U8 to Double)

Aligne all your code. You ve a lot of "spagheti" code.

It's not a bad think if your code need a lot of space. It will be easyer to read.

When tour code look good it is easyer to debug whout reading error

[kdmcmullan]

It's pretty nasty all right!

First thing I'd do is put all the locals into a cluster. Make this a type def and pipe it into the main loop as a shift register. This will start to force a bit of flow.

Next, replace the flat structures witha state machine. I'm a big fan of this architecture. It also means you can unbundle your "global cluster" once, but if you modify a component, you can bundle it up. Each state, basically passes to the next one. It will ook a bit futile at first becasue each state is only called once, but you will spot code portions which will want to jump around in the structure and this will eventually reduce the code size.

It actually looks like good fun in an engeineering, academic, nerdy kind of way!

[Rivetm]

Ah yes, I will have to look through the code and try to eliminate the coercion dots. Thanks, its a great point.

[cirrusio]

Uggh...I don't envy you .  Here are a couple of suggestions based on a quick look:

• I would suggest actually hooking up some of those controls rather than always using local variables.  It looks as if NONE of the controls or indicators are actually connected to anything.
• Consider using some of the architecture discussed extensively on this site.  Example: I might use a producer consumer architecture in which the producer simply listens for a command to be sent while the consumer ingests the command and does the required action.  It looks to me like you could get away with only three states:
  • Configure: configure all controls for first run.  In addition, open a connection to the serial port.  It looks to me like a lot of the code is simply a way to send commands through a VISA session and it is unclear to me why you might need to continually open and close the port.  For that matter, configure the port either through a ini file or just hard code it - if the port is always the same, it is unclear to me why the baud rate and parity might change from command to command.
  • Wait for command: here is where commands would be dequeued and appropriately acknowledged.
  • Quit: Close ports, files etc so nothing is dangling. 
• In the above example architecture, I would reccommend that the VI only do things while responding to commands: have the dequeue wait forever as well as the event structure wait forever.  In the producer loop, have the queue be destroyed when exit is requested - this will tell the consumer it is time to close.
• To pretty this up, I might suggest using Simon's Missing System Control Suite in this group.

I think that is all for now.  Implementing some of this should clean up the diagram A LOT.  Also, these are more fundamental LV issues - you might want to post in the discussion forums rather than here.

Cheers, Matt

[Drew.Rankin]

Actually, this looks a lot llike code I have been given in the past to "clean up."

One of the first things I do is to do a thorough analysis of just what the code is doing and write everything down. This allows me to organize overything into functional blocks or classes of code.

Next is to figure out what code is initialization and settings and what is actually part of the application. I also write some instrument drivers at this point as well.

I am a huge fan of the Event driven-Queued State Machine and the new offering of the Extensible Session Framework architectures; therefore, I look at everything through that bias. This architecture allows me to categorize the code into sections and go from there.

Finally, You should be limiting the displayed code to one screen width, or height-preferably one screen, period. This means lots of sub-vi's. I can see a lot of cases in the code that you have where the different frames could actually be put into sub vis and clean up the main diagram a bunch.

Consider using a tabbed interface or writting different screens that are called by button click. For example, machine setup, comms, manual control, auto mode, etc. Also, if you are using LV8 or higher, consider using an event driven architecture. This will save on polling the front panel to see what buttons have been pressed. I do like the cluster of booleans for control, but how are they reset when a command has been processed? Think about how those controls are used to switch program states.

Finallym it is best learned by doing. My first "clean up" three years ago was not the best result; however, it did teach me a lot and I have gotten a fair bit of work cleaning up other people's code. So I guess it wasn't too horrible!!

Good luck.

Drew

(CLD)

[Rivetm]

Matt, being new at this labview game I wanted some validation that my diagnosis was correct. Thanks for your comments, thats the way I was considering going. So at least my thinking is on the right track. In fact, I have started to fix this inherited code and the first thing I was trying to do is connect up some of those controls. But I am thinking that I will use queque'd event structure to handle the user interface part. But your suggestion to open the visa resource once, and close once is great; That sounds like standard programming. I'm not sure why it was done the way it was, but I believe I will change that also; Thanks alot.

[shred444]

If you think your application may need to be scalable in the future, design it using splitters so that it can resize without objects starting to float around.  It also helps you frame out your design a bit better

[S-T-G]

Drew, This is a little bit off-topic but what is, "...the new offering of the Extensible Session Framework architectures;"? I searched the NI site but didn't find anything. Thanks.

[Drew.Rankin]

Sorry for the late reply.

Have a look at http://decibel.ni.com/content/docs/DOC-12813 for more info on the session framework.

Drew