Restarting programs involving timing (and other problems)

[maxh]

First, I am new to LabVIEW, and to programming for that matter, so I apologize if I do a poor job of communicating on the topic.

This is the first program I have written. It is for controlling an apparatus involving heater(s) and solenoid valves controlling water and air flow. The device which this test rig will be cycling undergoes a thermal cycle involving a heating ramp followed by a water cooling period until the device drops to the hold temperature, then an air blast to dry the water cooling lines. Once the cycle completes, the program should increment a counter and do a few other chores I haven't programmed yet, then restart the cycle.

There is a manual control interface where the user can flip switches and monitor temperature, and an automatic control interface where (in theory) the user will enable and start the cycle, and can monitor temperature and other pertinent data. I wrote the program for manual control first (for which it works fine) and am now trying to implement the automatic control.

So my problems/questions:

1. The automatic control works for one cycle only. After the cycle ends, it will not restart. I have tried to accomplish this task using the boolean "time has elapsed" outputs from the timers in the heat and water/air sub VIs to determine when to hit the cycle start button. The "Cycle Reset Pulse" timer in the bottom right while loop should feed a FALSE boolean to the Cycle Start button (via a property node) for a few milliseconds, then change it back to TRUE, mimicking the action of manually cycling the button. It doesn't work, though, and I can't figure out why. Can you?

2. Also, after the first cycle which works fine, manually restarting it by pressing the cycle start button seems to work, but it turns out that the water cooling portion doesn't work. Why not?

3. The bottom left while loop contains my attempt at turning off all output bits before terminating the program upon pressing the main STOP button. It kind of works, but sporadically. It doesn't turn all bits off (or on), and sometimes it doesn't turn off all stop buttons. But sometimes it does. Seemingly at random. What have I done wrong here?

Any help or suggestions would be greatly appreciated. I am well aware that there are probably way better approaches to this program, and I would like to hear them. This is simply the first thing my completely inexperienced mind came up with.

(I have zipped all VIs used. The main one is test_rig_control_6.vi)

Download File:post-6787-1164129997.zip

[mross]

I can't run it becasue DBitOut.vi is missing, so I have to make comments without running it.

First thing, lose the sequence frame. It adds nothing. The data flowing through the wires accomplishes the same thing. I suspect some of your questions will be resolved when you get a better intuitive grip of dataflow. Example: The large upper and lower left loops will not function until the data from the DAQ Board # is delivered to them. The upper loop will not send the boolean to the lower right loop until after you manually stop the upper loop. A single sequence frame is used to make certain a group of functions have fhinished their work before proceeding, such as intializations before full operation of equipment. You wantto let LabVIEW decide when to run things as much as possible; that means avoiding sequences for the most part.

I like your use of the Tab control to gather like functions.

Have yoo tried using hightlight mode yet (the light bulb icon)? This is tedious, but it will start to show you how the data progresses around the Block Diagram (BD). Also, the pause button, step through/step over, and the use of breakpoints and probes are all excellent tools for figuring out glitches.

You have a combination of machine operations, some of which need to be completed as a group without interuptions, and you have user inputs the program should respond to. There is an architecture called User Event Driven Producer Consumer that can do a sweet job of this. I will try and find a simple example to send you. BUt you need to learn how to use the Eent Structure, this will be very helpful.

Can you resend with the missing file while I try to locate a decent simple example?

Mike

First, I am new to LabVIEW, and to programming for that matter, so I apologize if I do a poor job of communicating on the topic.

This is the first program I have written. It is for controlling an apparatus involving heater(s) and solenoid valves controlling water and air flow. The device which this test rig will be cycling undergoes a thermal cycle involving a heating ramp followed by a water cooling period until the device drops to the hold temperature, then an air blast to dry the water cooling lines. Once the cycle completes, the program should increment a counter and do a few other chores I haven't programmed yet, then restart the cycle.

There is a manual control interface where the user can flip switches and monitor temperature, and an automatic control interface where (in theory) the user will enable and start the cycle, and can monitor temperature and other pertinent data. I wrote the program for manual control first (for which it works fine) and am now trying to implement the automatic control.

So my problems/questions:

1. The automatic control works for one cycle only. After the cycle ends, it will not restart. I have tried to accomplish this task using the boolean "time has elapsed" outputs from the timers in the heat and water/air sub VIs to determine when to hit the cycle start button. The "Cycle Reset Pulse" timer in the bottom right while loop should feed a FALSE boolean to the Cycle Start button (via a property node) for a few milliseconds, then change it back to TRUE, mimicking the action of manually cycling the button. It doesn't work, though, and I can't figure out why. Can you?

2. Also, after the first cycle which works fine, manually restarting it by pressing the cycle start button seems to work, but it turns out that the water cooling portion doesn't work. Why not?

3. The bottom left while loop contains my attempt at turning off all output bits before terminating the program upon pressing the main STOP button. It kind of works, but sporadically. It doesn't turn all bits off (or on), and sometimes it doesn't turn off all stop buttons. But sometimes it does. Seemingly at random. What have I done wrong here?

Any help or suggestions would be greatly appreciated. I am well aware that there are probably way better approaches to this program, and I would like to hear them. This is simply the first thing my completely inexperienced mind came up with.

(I have zipped all VIs used. The main one is test_rig_control_6.vi)

[maxh]

Thank you for the insights so far! I have, indeed, been becoming more familiar with the data flow concept and have already removed one other unnecessary sequence structure. This main one will be next.

Here's the files again, this time with the missing VI included: Download File:post-6787-1164133945.zip

What do you think about the use of the sequence structure in the lower, left while loop where I try to sequence the shutdown of the program upon pushing the stop button? Do you have any insight into why it might not work? BTW, just a minute ago I ran the program without my DAQ boards plugged in and the stop button seemed to work just fine every time. Perhaps the error associated with not having the boards there ("Invalid board number") left the program stopped, not calculating intensely, so timing issues worked out?

P.S. If you're curious, I've documented my intentions for the program operation as text notes inside of most of my sub VIs.

[mross]

Thank you for the insights so far! I have, indeed, been becoming more familiar with the data flow concept and have already removed one other unnecessary sequence structure. This main one will be next.

Here's the files again, this time with the missing VI included: Download File:post-6787-1164133945.zip

What do you think about the use of the sequence structure in the lower, left while loop where I try to sequence the shutdown of the program upon pushing the stop button? Do you have any insight into why it might not work? BTW, just a minute ago I ran the program without my DAQ boards plugged in and the stop button seemed to work just fine every time. Perhaps the error associated with not having the boards there ("Invalid board number") left the program stopped, not calculating intensely, so timing issues worked out?

P.S. If you're curious, I've documented my intentions for the program operation as text notes inside of most of my sub VIs.

I think you could get rid of the sequence frame and it would work the same. All the sequence does is make shure the subvi's run 20ms after the case is called. Maybe that is important but I can't see why the subvis shouldn't just go for it as soon as the case is called.

You should really turn on the light bulb and watch. Put a breakpoint right after the stop button and it will switch to hightlight mode every time it get to that point. Run it like that with and without the sequence structure to see what I mean.

I think your documentation is great and I do the same myself. Often writing the doc helps me get clear on what exactly I am trying to do.

However, you don't have any documentation on the main vi to describe the progress through the procedures. I haven't got it in my mind what you want to do yet. I tend to think in flow charts. One of the reasons I like the event driven producer consumer is it is a clear outgrowth from a flow chart for me.

If I can get straight how I think you want yours to run I can try to make you a model. I didn't find the example I was after.

Mike

[maxh]

I removed the main sequence structure and annotated the main VI's block diagram to better describe the intended operation. It's attached and I've included a screenshot for people that don't feel like downloading it.

The VI does run fine wth the sequence structure gone.

I used the "highlight execution" feature and discovered that the bottom right while loop (which I was trying to use to restart the cycle after it ends) was never turning on. I tried to be clever and wire the error output of my board initialization VI to the while loop so that it would start right away, but it still would not start because it was waiting on the boolean coming from the main while loop. I then tried moving everything in the "restart" while loop into the main while loop and the cycle start button perpetually remains false. When I manually press it it instantly pops back up.

So now I'm going to take a little break and run some real wires!

Thank you for the help.

Annotated VI:

Download File:post-6787-1164147441.vi

Screenshot:

[mross]

I used the "highlight execution" feature and discovered that the bottom right while loop (which I was trying to use to restart the cycle after it ends) was never turning on. I tried to be clever and wire the error output of my board initialization VI to the while loop so that it would start right away, but it still would not start because it was waiting on the boolean coming from the main while loop.

Tha's what I said!

"The upper loop will not send the boolean to the lower right loop until after you manually stop the upper loop."

Anyway, you needed to have that revelation about when data is passed by loops. The same is true with the walls of sequences.

The way to think about structures and dataflow is as follows:

All the input tunnels on the border have to get data before a loop or structure (formula nodes, event structure, all of them) will start.

The loop has to finish its work before the output tunnels are filled and can pass data to subsequent nodes.

Every tunnel on a border represents a copy of the data, so be careful about wiring large gobs of data (huge arrays or clusters) to border if it is not necessary.

I am playing around with a vi for you that is an event driven producer consumer. This uses a system of queued eunmerated phrases (called ENUM controls). The queue functions as a FIFO. You load a series of commands in the queue - a while loop with a case structure in it responds to the queued commands by selecting what case it runs each time the loop increments.

You can enqueue commands in the event structure so a cursor pick commands those cases to be run in order. You can also have decisions made in the cases that enqueue further commands, or have other loops running that enqueue commands.

I'll say more when I send the vi.

Mike

[maxh]

I read a good chunk of the latest LabVIEW for Everyone and restructured my program from the ground up. It works just the way I want it to. I haven't worked on it in well over a month, but if I do ever get to work on this project again, there are a couple more minor things I want to add, such as the analysis of my pressure test data and reporting to a file and/or web page. No problem to do.

So check it out and tell me what you think.

Download File:post-6787-1169848555.zip

Unzip, navigate to \...\auto\currently_used and run test_rig_auto_ctrl_3.vi.

It has an interactive UI. The front panel is a tab control and in use I'll have the tabs at the top turned off. Upon running the VI the user is brought to the first tab, "board config", where they can set parameters. Once they're done, they press the "next>" button down at the bottom and they're brought to the "cycle config" tab. Here they can alter the cycle parameters and when they're done they have the choice of going back to board config, going straight to manual control, or starting the automatic cycling of the test rig. On this page they can also set the program to pause on the results page after every cycle of the test rig, or not.

While the program is running, the "running program display" tab is activated and from here, the user can enter the manual mode at any time, and can also change back and forth between the "pause on results page" option. The test rig will usually be running 24/7 without any user watching, so it will usually be set not to pause on the results page.

To make this happen, I stuck a case structure in a while loop (to make a state machine) but I also stuck an event structure in there for doing fun things with. I use it for a couple of purposes. First, whenever I want the program to pause (such as when waiting on the user to enter information into the config pages) I wire a -1 to the timing terminal to cause it to never timeout. Second, I use it to change the flow of the state machine. When you, for instance, press one of the buttons to go to the manual control page, the event case is activated which will feed out the "manual" case constant and a boolean to correctly control the selector whose output feeds into the shift register which carries the case structure's next value.

Anyways, critiques, please? Do keep in mind this is my second labview program (a revision of my first one).