hardware push button

[RavensFan]

You will need to use a digital input or two on your data acquisition card.  So the press of the button would complete the path from +5VDC to the digital input.  (Check the wiring diagrams for the DAQ card to be sure.)

Then you will need to add some data acquisition loops to run and read the digital input lines.  I would recommend running them in separate loops that run fairly fast so that they can detect even quick presses of the button.  (Perhaps 50 msec loop?  may need some experimentation).

Next step would be to get the fact a button was pressed into the rest of your program.  I'm sure there are numerous ways to do this.  One I've used before is local variables of a boolean indicator.  With proper programming techniques, the local variables wouldn't be evil and would work.  Since you can't have a latch action on .  The digital input when true sets the boolean indicator to true.  Read that boolean indicator in your main code and reset it to false yourself once it is read and you act on it.

A better alternative would be to use a notifier for the digital input reading part of the program to send a message to where your current software start button is now.

[smm]

---

Ravens Fan wrote:

A better alternative would be to use a notifier for the digital input reading part of the program to send a message to where your current software start button is now.

---

How do you suggest this could be done?

[GerdW]

Hi smm,

cleaned up your subvi, just a little bit by straight wiring & removing unneccessary structures
There are several more things to do...

[smm]

Thanks, but what exactlyare you talking about? What more is to be done? Any hints, tips, anything?

[johnsold]

On reading the hardware button: Read the DAQ input in a parallel loop. When the button changes, signal to the main loop via notifier, queue, or Action Engine. Any of these methods can produce a very responsive program.

On general improvements to your program: Replace local variables with wires and shift registers.
Change the long waits so the program can respond quickly to external inputs from the hardware or the user interface.
Eliminate sequence structures. Use dataflow.
You have code which is duplicated many places. Move this into subVIs. One example is the boolean array to Array Subset to Index Array to case selector. This could be a subVI with the array, subset size and start index, and the selector index as inputs. The outputs would be the subarrays for display and the selector boolean.
Put the DAQ and GUI code in separate parallel loops. Add an event structure to the GUI loop. Queues are good for communicating between loops.

Lynn

[GerdW]

Hi smm,

as Lynn told you: use more subvis, remove waits, cleanup...

For your main vi: I would replace all those single controls/indicators with clusters! Each unit would only be represented by two clusters (one with controls, the other with indicators). Then your subvi would only need 3 inputs and 3 outputs (visa, cluster, error each). The block diagram will be much cleaner!
It's also "critical" to have one big string indicator to show messages from several subvis. You should append those messages to the existing ones instead of overwriting older ones by using locals... A LV2-style global (aka action engine) will be a great help here.


Message Edited by GerdW on 02-01-2008 09:48 AM

[smm]

I cannot remove the waits becuase they are imperative for the functioning of the thermostats. They take the capacitor discharge and the general thermostat test procedure into consideration.

To clean up the code (man this is turning into a pain), I cannot follow the concept of action engines.

---

GerdW wrote:
Hi smm,

as Lynn told you: use more subvis, remove waits, cleanup...

For your main vi: I would replace all those single controls/indicators with clusters! Each unit would only be represented by two clusters (one with controls, the other with indicators). Then your subvi would only need 3 inputs and 3 outputs (visa, cluster, error each). The block diagram will be much cleaner!

---

How can the clusters thing be done?

[smm]

I thought of something. What if I replace the start and stop buttons in the block diagram with a daqmx read. So if it reads 1 it starts. if it reads 0 it stops.

So it's like the soft button but only uses the DAQ. Do you think that'll work?

[GerdW]

Hi smm,

that's what we're talking about all the time

[johnsold]

GerdW is right. We have all been talking about using DAQ for the buttons.

Look at the Parallel state dataflow demo.vi I posted earlier in this thread. It implements delays of 400 ms and 5000 ms (LED blink timing) but stops within 20 ms of the Stop button being pressed. It "waits" but none of the states has a Wait function. This implementation works and will even allow multiple, different waits to run simultaneously by using separate shift registers for the end of wait time for each wait. The loop has a 20 ms wait to limit how fast it runs and to allow CPU resource sharing with parallel loops (although none are in this demo).

Lynn