blinking boolean outputs

[EvenDeejay]

Hi!

I would just come with a tip for you regarding UI. I'm quite new to Labview and in the beginning I found the standard UI very boring. After a while I found that I could use the system look rather that the classic look. I also managed to change some colors, adding icons etc, to make my UI more interesting, eyecatching and comfortable to use. Still it was not "good" enough for me, so after some research here on the forum I found a link to The UI Interest Group. Here you can find many useful tips on how to make excellent UI's. SimonH have many videos and libraries you can download and use in future projects.

Maybe a bit off-topic, but I hope it helps since you asked how to change color.

Regards,

Even

[uberdog57]

Thanks, I really want to move this design to varying the duty cycle on a DO, so I will want to be able to vary the blink based on other variables.

I'm working on getting my head around a previous post using arrays...but now I have a headache...uberdog's a hardware guy!

[uberdog57]

Thanks for pushing me in the deep end!

This looks like an elegant design, I will work to understand it. I will ultimately migrate the design to vary the duty cycle on a digital out to control some pumps based on other variables and thresholds. This is a good start for me to work with and understand...thanks.

[tbob]

As long as you are giving thanks to push you off the deep end, here is another push in that direction.  See the attached VI.  Notice how compact the block diagram is.  Notice that the front panel doesn't hurt your eyes,

In the block diagram, I'm using an event structure.  Don't have to continuously poll the slides and alarm settings.  When either a slide value or an alarm value is changed, the proper event will fire (like an interrupt), and only the code inside that event case will execute.  The code is the same as your original with the exception of using a Selector function instead of a Case structure.  The Selector is more compact when having only one item to select.

When nothing is being changed, the only code that runs is the Timeout event.  It runs every so many milliseconds, as set by the Blink Rate.  Notice the case structure inside.  If the over limit flag (top shift register) is not true, nothing happens.  If it is True (as set inside the event case for Slide 2 and Alarm 2 Value Change) then the code inside the True case executes.  Notice that whatever value is in the blink state shift register gets inverted.  So every so many milliseconds, the boolean changes state, which appears as a blinking LED.  The boolean inside the case structure is a local variable.

Study this vi.  It contains a lot of information.  Compare it to your original to learn better programming methods.

[altenbach]

Remember that operating on arrays is always simpler, because it eliminates duplicate code. In this particular case, you can make the controls and indicators also arrays. Now the program is more easily scalable. In you need to add another channel, simply enlarge the arrays, no change in code needed. 😉

The slides (which seem to simulate your hardware and are probably not used in the final design) cannot be in an array unless all the scale ranges are the same. In this case you could use a cluster instead.

I don't think that events are the right tool to use, because they are geared towards handling user interaction. I assume that you data comes in at regular intervals from your measuring device and not triggered by the operator.

Here's a quick modification showing the use of arrays. There are many other ways to do this, just play. 😄

[tbob]

---

@altenbach wrote:

Remember that operating on arrays is always simpler, because it eliminates duplicate code. In this particular case, you can make the controls and indicators also arrays. Now the program is more easily scalable. In you need to add another channel, simply enlarge the arrays, no change in code needed. 😉

The slides (which seem to simulate your hardware and are probably not used in the final design) cannot be in an array unless all the scale ranges are the same. In this case you could use a cluster instead.

I don't think that events are the right tool to use, because they are geared towards handling user interaction. I assume that you data comes in at regular intervals from your measuring device and not triggered by the operator.

Here's a quick modification showing the use of arrays. There are many other ways to do this, just play. 😄

---

I agree that using arrays makes it more scalable.  I was just too lazy to include it in my code.  Besides, I wanted to take one step at a time.

The slide control is probably a simulation tool and the real data is probably obtained by a DAQ or something like that.  But I'm sure the alarm controls are set by the user.  Sometimes other actions need to go on besides just polling for these data points, which is why I suggested the event structure.  If this is the only thing the code will do, then a polling loop will do just fine.  I've been in the SCADA world before, and everything is event driven.  Even the data coming in from a DAQ will trigger an event.  So I have to disagree with you and suggest that the event structure is best.  There is sure to be other things going on besides just reading 3 inputs.  Well, I have been known to be wrong at times....