Newbie needs help with timer control

[gronfelt]

I need to write a program that is supposed to control 8 different lamps, working as a programmable timer. I wan't to be able to, for each lamp, to set an on time (in minutes) and an off time (also in minutes) and then I wan't the program to switch between on and off with the specified intervals.

I have a DAQ with DAQmx and 8 digital I/O:s and I've figured out how to send the correct signal. It's the timing function that I really can't figure out.

I've tried a few models with FOR-loops or Sequences with Wait-functions, but the problem is that I seem to loose control of the program while it waits for the Wait-function to finish. I can't end the programs main While-loop etc. So far I've only worked with one channel and I can only imagine the trouble of getting 8 different Wait-functions to collaborate, so it seems to me there must be a better way.

So what I need is perhaps a few pointers telling me where to start, I seem to be stuck with the wrong thinking. Perhaps a flowchart or som pseudocode would help, or even better, a Labview-example.

Summary of the program function:

* 8 channels, to be controlled either manually or by timer

* Each channel to be controlled individually, with different timer settings

* Different settings for on and off times.

Finally I would like to apologize if I have posted in the wrong category.

[crelf]

QUOTE(gronfelt @ Oct 28 2007, 05:01 PM)

I need to write a program that is supposed to control 8 different lamps, working as a programmable timer.

Please post your code so we can try to find out what the problem is.

[mross]

QUOTE(gronfelt @ Oct 28 2007, 03:01 AM)

I need to write a program that is supposed to control 8 different lamps, working as a programmable timer. I wan't to be able to, for each lamp, to set an on time (in minutes) and an off time (also in minutes) and then I wan't the program to switch between on and off with the specified intervals.

I have a DAQ with DAQmx and 8 digital I/O:s and I've figured out how to send the correct signal. It's the timing function that I really can't figure out.

I've tried a few models with FOR-loops or Sequences with Wait-functions, but the problem is that I seem to loose control of the program while it waits for the Wait-function to finish. I can't end the programs main While-loop etc. So far I've only worked with one channel and I can only imagine the trouble of getting 8 different Wait-functions to collaborate, so it seems to me there must be a better way.

So what I need is perhaps a few pointers telling me where to start, I seem to be stuck with the wrong thinking. Perhaps a flowchart or som pseudocode would help, or even better, a Labview-example.

Summary of the program function:

* 8 channels, to be controlled either manually or by timer

* Each channel to be controlled individually, with different timer settings

* Different settings for on and off times.

Finally I would like to apologize if I have posted in the wrong category.

I checked the upload and saw that it omitted the queue control and a couple small utility vis. So ignore that.

Still not right ---try the upload called Light Experiment Folder.zip

Nobody jumped all over answering this becasue it isn't exactly simple to do. There are also other ways to do this. This just happens to be how I think about it. I hope someone offers up another method so I can learn myself.

==========================

So here is what occurs to me.

You need independent functions, but what you have described sounds like it has no parallel operations.

(It never hurts to show us what you have done when asking for help.)

Assumptions:

There is a default mode that the lights each follow a default on/off shcedule unless operation of the channel is set to manual.

User input is required to activate and terminate manual mode for a light.

When the manual mode is terminated, the individual light returns to the default schedule.

If the scheduled on time for a light is set to 0 then the light is off, if the off time is set to 0 then the light remains lit coontinuously.

When manual mode for a light is activated, the mode is only achieved after the light is turned off - if the light is on, its on duration must complete before the manual mode can be activated.

You have the following controls on the FP:

One boolean toggle switch for each light channel that toggles between on and off that is used to activate and deactivate manual mode.

Two numerical controls for each light, one of which sets the on time and the other off duration.

A Stop All operations boolean push button.

Uploaded is a file called Light Experiment.zip

======================================================================

What I have provided has only 4 loops, you can do the necessary grunt work to make it do 8.

I have not bothered with the actual write to line functions that will command the digital lines to switch state. I just turn on an off the lights on the front panel. You can substitue what you need in the Automatic and Manual cases where that code would go. It sounds like you have already figured this part out.

The VI needs a little (heh) explaining. If you have not used queues, you are about to get educated. A queue is a FIFO buffer. You get to define what goes in the queue - in this case I have made the queue elements to be an ENUM. The User Event structure loads the 4 queues that run the 4 parallel loops with the value of the ENUM. Every time a function loop runs (as opposed to the user event loop) it reads its queue for either the Manual, Automatic, or Stop All commands and performs prescribed operations in the corresponding case. If there is nothing in the queue it just waits until a command is placed there.

This is what is called the "user event driven producer consumer architechture." It is an excellent way to run parallel functions that are sometimes commanded by a user. The paralle loops can also be machine driven - reacting to information from transducers and in response to analysis - not human driven.

This is a pretty straight forward implementation of this architecture, but it is not trivial when you have many loops running as you can see. Some important things to note:

The VI that times the loops is set to be re-entrant. If it is not re-entrant then the many calls to the VI conflict while trying to access the same shared subroutine. Re-enetrancy allows that each instance stands alone and does not interfere with the others. Rentrancy is set by accessing the Vi Properties/Exectution of the "Wait for Multiple with boolean pass through.vi" subroutine. This vi is a simple wrapper that allows the re-entrancy and the pass through allows control of the data flow and sequencing without resorting to sequence structures. Observe that I wire the boolean for the light through the Wait vi. The wire then sequences the operations. If you aren't clear on data flow "sequencing," ask about it.

The logic that manages the Stop function was a head scratcher for me for a while. I never used the x.implies.y before.

There are error cluster wires routed all over that are not necessary, but I have a habit of putting these in as I go along. The wisdom of that is another lesson. OUt of habit I release the queues when all is finished.

If you have any questions, just ask.

Enjoy,

Mike

[PaulL]

I am working on a software timer that I think does what you want.

We want to run a timer in its own thread. (In my case I am using the state pattern. I start a timer and can transition to the next state. If a timeout event occurs the current state handles the timeout event appropriately.) In other words, I am constructing an asynchronous controller. Fortunately the "Elapsed Time" express VI runs in its own thread. I decided to start it in its own thread and update signals (in my case networked shared variables) based on inputs from the caller. I use VI server to change the values of the inputs and then execute my timer VI with "Wait Until Done" = False. I will pass in the timeTarget and the signal paths from my application when I call my startTimer.VI.

[Notes: The result is good and clean, although I have to integrate it fully in my application still. The solution uses some intermediate concepts, but then the problem is nontrivial. I am using DataSocket because I want to set the shared variable targets programmatically. Also, the DataSocket Read and Write wrappers just include the DataSocket Read and Write VIs and use the same inputs. This is only necessary because of a bug in 8.5.]

Are there any comments or suggestions?

[TobyD]

QUOTE(gronfelt @ Oct 28 2007, 12:01 AM)

I need to write a program that is supposed to control 8 different lamps, working as a programmable timer. I wan't to be able to, for each lamp, to set an on time (in minutes) and an off time (also in minutes) and then I wan't the program to switch between on and off with the specified intervals.

Here's another simple example with three lights. The On and Off times are in ms, but that could easily be changed to minutes. I didn't spend too much time making it pretty - just wanted to give you an idea.

-Toby

Download File:post-8758-1193782874.vi

[mross]

QUOTE(TobyD @ Oct 30 2007, 06:25 PM)

Here's another simple example with three lights. The On and Off times are in ms, but that could easily be changed to minutes. I didn't spend too much time making it pretty - just wanted to give you an idea.

-Toby

Download File:post-8758-1193782874.vi

That is nice. Much less trouble than my example. I knew there had to be a better way.

Though as I was looking at it I kept thinking, I wouldn't trust that - running the loop every 1ms, clearly it works for lighting 3 booleans. But the loops aren't independent so if one light operation runs slow, it would hold up the others. Dataflow and all that.

I added a subtraction between the start and finish millisecond times for one lamp and monitored how close to the commanded time the iterations were running, and it wasn't just so. Adding a delay to the on or off case is seen by the subtraction.

Adding a large enough delay shows that one loop running slowly messes up the other automatic functions.

If there were 8 Write to Line operations would it keep up? If one of the write operations were taking longer than 1ms the timing would be off by that amount every iteration. That wouldn’t be much of a problem for lights that are lit for minutes - as long as the writes that don't change state are all less than 1ms. But if there was a lag for no change operations, then that would accumulate and might cause the automatic function to be off. For example if one Write to Line took 1.5ms, then each iteration would casue a 0.5ms lag and 1.5ms/iteration cycle time. Over the entire on or off time that does add up. Say you had a light on for an hour that 0.5ms would add up to 30 seconds delay. It would be possible to test for no change and skip the write if it isn't needed. That would solve any pernicious lag problems.

This is a good and elegant solution as long as some stray delays don't add up in the long run.

Mike

[TobyD]

QUOTE(mross @ Nov 1 2007, 11:02 AM)

Though as I was looking at it I kept thinking, I wouldn't trust that - running the loop every 1ms, clearly it works for lighting 3 booleans. But the loops aren't independent so if one light operation runs slow, it would hold up the others. Dataflow and all that.

That would certainly be something to watch for. You could increase the delay, which would eliminate any of the problems you bring up, but each interation then has the potential to be off by as much the loop delay. It would probably be safer to go with a 5-10ms loop delay - especially for an application like this where the on/off times are measures in minutes. Incandescent bulbs usually have an illumination time of >15ms anyway.