building large programs in labview

[Coq_Rouge]

---

dsavir wrote:

Hi,

We have a LV program that numbers 100s of VIs. It was written in a "patches" method: A basic program was written, then the customers wanted a new feature and a "patch" was added, and then another, etc. The result is... a horrendous program, that is almost impossible to update without changing everything.

---

Chuckle, chuckle! I wounded how often this happens. Your project started out as a doghouse, but after several "patches".  you end up with a apartment building, but it is still built on the doghouse foundation wall. So the construction is quite shaky. So sometimes it is better to tear things down and build a new foundation wall, with brand new materials. Reusing only well documented core functions.

I also have a comment on using globals, and locals. I think it is wrong to ban them. But they should be used with care. Identify the risk by using them like race conditions, the amount of memory used, and how often they are updated.  Never use them as tool for cleaning up diagrams. It is several more pitfalls, but as I said the keywords are "use with care"

[dsavir]

Hi all,

I read a lot and I tried implementing a simple sub program using the OO aproach (though without classes). The program has to write to a log file, so I wanted to write the follwoing subvis:

open log file

write log file

close log file

where write log file receives an enum as input with the various possible commands to write: Sending, Receiving.

so log file looks like this:

Connecting...

Sending: <data>

Recieving:<data>

...

Ending connection.

My problem is: If I add a command at some point, for example Calculating, I update the enum and I need to update all the calls to the write log vi, which is exactly what I wanted to avoid. I thought a typedef would solve this problem, but I can't see a way to make an enum a typedef (only clusters).

What is the solution to this? What am I missing? Should I write seperate files to write the Recieve command and the Sending command? Both do the same, just Sending tacks the string"Sending" before the data and Receiving tacks "Receiving" before the data.

Thanks for your help!

Danielle 

[Ben]

---

dsavir wrote:

...

My problem is: If I add a command at some point, for example Calculating, I update the enum and I need to update all the calls to the write log vi, which is exactly what I wanted to avoid. I thought a typedef would solve this problem, but I can't see a way to make an enum a typedef (only clusters).

....

Danielle 

---

Your thought is correct!

1) Righ-click on a FP instance of the enum (right-click and do change to control if you only have BD constants since this option only available for controls)

2) In the editor change the drop-down from "control" to type def.

3) Save the type-defed enum

4) Close the editor

5) Go to all instances of the enum and replace same with your type-def'd version.

Ben

[dsavir]

Thanks, Ben, it works great now!

Danielle

[dsavir]

Hi all!

To get an idea of what I wanted to do, I rewrote a small sub-program of ours as an object-oriented queued state machine.

After realizing I had no idea what I as doing, I think I'm getting the hang of it and hopefully the finished program will be a pleasure to read and mantain.

However, I have two unsolved issues:

First, how do I document this? I find that even in my small program remembering what each state does and where each state leads to is a problem. Other than creating a flow diagram and updating it every time I add a state, are there any other ideas? Do you have a particular program that makes this easier (Word is a pain...)?

Second, I would like to add some sort of logger for debugging purposes. For this program it is mostly unecessary as it's small and easy, but the purpose of this was to prepare myself for rewriting our large program and debugging is a mess.

I would like some way for the customer to create a log file that shows the state of our important variables and the current state. However, I don't want to change the logger every time I change something in the main program. I also don't want the logger to record every single change of every single value because then the file will be too big to understand. This logger should work also when the program is compiled so that the customer can send us a "bug log".

Some background: until now, when customers have bugs we try to:

1) solve by phone/email

2) try to recreate the bug in the company (doesn't always suceed)

3) send someone to the customer to try to figure out the problem directly (almost impossible as only the compiled version is at the customer).

It would be great if we could tell the customer: "turn on the logger, do again whatever caused the bug, and send us the log".

Is this possible? How have other people solved this problem?

Thanks for all your help!

Danielle

[Ben]

RE: Documenting state machines...

There used to be a State Diagram Editor that made this easy but sadly in was dropped.

I usually keep the SM in a PowerPoint doc since I start with the design before I drop node one of a VI. Yes its a pain but is better than using paint.

We have an Event Logger that I wrote back in LV 6 that is used in many of our apps that I am not allowed to post. It is a set of VI that launch a background process that logs events. The other VIs in the set post Even message to a queue to be writien to disk. There are also a set of "diag" functions that allow us to set detailed logging so we can go back and chase the interaction of widgets.

I hope that gives you some inspiration,

Ben

[dsavir]

Hi Ben!

The event logger sounds interesting, we'll try to do something similar (expect more questions about that ;)).

About the PowerPoint SM: doesn't it become terribly complicated? Only the init states are known in advance; all the rest is: user does this-> we do that. So we get a sub-state machine for every user action. so your PP doc must be huge and have lots of sub-state machines. How do you make it readable?

Thanks,

Danielle

[Ben]

---

dsavir wrote:

Hi Ben!

The event logger sounds interesting, we'll try to do something similar (expect more questions about that ;)).

About the PowerPoint SM: doesn't it become terribly complicated? Only the init states are known in advance; all the rest is: user does this-> we do that. So we get a sub-state machine for every user action. so your PP doc must be huge and have lots of sub-state machines. How do you make it readable?

Thanks,

Danielle

---

Please down load and review the docs I posted in this thread. The reason I suggest downloading is there are notes in the PP presentation. Those docs represent two different apps that I develop a while ago. One ties together a bunch of widgets to test catalysts and the other was designed to test TPV (therom-photo-voltaic) diodes using a rack of HP gear.

If anyone has any commnets on those documents, "let er fly", since I am hear to learn.

Ben

[Albert.Geven]

Another way to document a statemachine that is que'd message handler is with a spreadsheet program like excel.

each state has a list of states that are called from that state in all cases.

and each state has a description (documentation) of why this state exists.

At least you get a feeling for yourself what went wrong in the 51th state......

here is a small .xls example without the description 

And a typedef enum can easily generate a string of states when adding crlf after each %s of the enum in a string. See attached.vi

[dsavir]

Hi,

Thanks for all the info!

Ben, you wrote all this before you started writing? That is impressive. Seriously. You wouldn't be open for some freelance work, by any chance? 🙂

Sigh. Well, we're trying to design before we code, but keep seeing this situation: we design something, and then when we start implementing, we see something we didn't think about, so we play with it a bit until we find something that works (usually redesigning the whole project in the process). We have a lot to learn...

About the Event logger - how is the communication between the main logger and the vi's done? Also, how do you make this general? Or do you make an event logger for each project? After all, each project has different events. Does the event logger work in the compiled version as well?

In general, is there a good Labview book you would recommend that would help us design a large project (and document it)?

Thanks all,

Danielle