15 replies to this topic

[AustinCann]

Hello everybody.
I have test tomorrow and struggling to make my slider and knobs work on boiler controller example.
It works fine until they trigger the front panel. After this point, any action on them causes no effect.
It could be very well the case that I will be involved with these tomorrow. Will appreciate if somebody could point me in the right direction. Please find attaced my solution.
As I did it fairly quickly and still have 45 minutes, I would have worked on my block diagram to make it look more cleaner and I am doing this now.
Please help.

Kind Regards
Austin

Attached Files

•  Controller Software.zip   481.03K   56 downloads

[jcarmody]

I'm not clear on your problem, but I see that you don't respond to events for anything except the 'Shutdown' boolean. The Case Structure in your consumer loop is looking for the 'Consumer Command' from the producer, which never comes.

[AustinCann]

Yes. Consumer loop in this case is pretty much a standard state machine with queues to sequence through each state. If you see from the initialize state, I have used Controlller_Consumer Datatype to in all the cases to execute the state machine.

For shutdown, master loop takes control, flush the queue and add in the queue command for shutdown.

[todd]

As jcarmody said, the user Event Structure only has a case for Shutdown. In your consumer loop, the FP terminals are read before any dequeue happens.

[AustinCann]

From my experience as long as the controls/indicators are in a while loop, the values are readable by the application built as long as the while loop termination condition is not satisfied(usually stop control). A simple test is to place a while loop, wire a boolean control to the condition terminal, drop Get date time in second function and wire an indicator to the output. This will read the present time continuously.
In my application, I used consumer loop to open reference to the display loop and run the front panel update task completely
independently. So at the start of every execution, the consumer loop reads the controls required for the subvi in the case which is going to be executed based on the value of the Consumer Command available after dequeuing, carry out all execution tasks such as algorithms etc and pass the data to display loop to update the indicators.

The dequeue function being used in the consumer loop only dequeues the "name of the case" which is wired to the selector terminals and it is executed at the same time as the controls according to the laws of data flow programming.
The dequeue function being used in the display loop dequeues the data sent from consumer loop so it would never execute prior to the execution of the consumer loop.

Sorry Todd nothing personal, but I dont think you have understood the design architecture.

[asbo]

You are correct about the behavior of the simple example you describe, but your consumer loop is not the same as that example at all. As soon as the consumer while loop begins a new iteration, your control values are read. Then, whenever the dequeue finally gets an element, all of the input values (probably with the exception of "Flame Sensor Value(%)") will be stale. I haven't looked any further into the logic because I'm not familiar with the requirements of this example, but Todd is 100% correct about the behavior of the controls in the consumer loop.

I don't understand why you put the "Flame Sensor Value(%)" terminal after the case structure in a sequence structure, or why you have a 50ms delay in a blocked loop.

Wrapping the controls in a sequence structure, for example, will will ensure the correct values are passed into the case structure:

Personally, I think that your consumer should not be interacting with controls at all. The producer should read values, and pass the data with the command to the consumer. Since you have a display loop, the consumer loop shouldn't have any terminals, references, locals or property nodes in it. For example, you have a subVI which uses a references to change the blinking property of the Pilot boolean.

[jcarmody]

Hello everybody.
I have test tomorrow [...]

How'd it go?

[todd]

Sorry Todd nothing personal, but I dont think you have understood the design architecture.

No offense taken. I agree that I don't understand your design architecture. I disagree that the control values are read AFTER the dequeue element primitive. You can see it in your VI if you enable Highlight Execution. Attached is my weak attempt to show it in a simpler way. Note that there are always more Y values on the front panel than Xs.

Attached Thumbnails

• 

Edited by todd, 05 March 2012 - 06:17 PM.

[AustinCann]

Documentation- Hopefully >=9.5
Functionality-
File IO requirement- didnt finish
Start up Initialization- Completed
Start up process, required updating a status indicator + elapsed time indicator for few seconds- completed.
After above, if application meets some conditions e.g ( numeric slider value greater than x) then update status indicator and elapsed time indicator. Completed.
After above, another set of conditions and then update status indicator if those are satisfied. Completed.

At this point, allow user to make some selections, after which run the controller.

Controller Stop + Shutdown File IO requirement : Didnt finish.

Style: Did not use local variables, used producer consumer and display loop, was comparitively neater. But used many references in the
consumer loop and property nodes in the display loop. Are these acceptable?

[jcarmody]

[...] Style: Did not use local variables, used producer consumer and display loop, was comparitively neater. But used many references in the
consumer loop and property nodes in the display loop. Are these acceptable?

I recall that a P-C architecture was more complicated than necessary for my exam and the practice problems. It might have led you into using references/property nodes unnecessarily.

[...] Personally, I think that your consumer should not be interacting with controls at all. The producer should read values, and pass the data with the command to the consumer. Since you have a display loop, the consumer loop shouldn't have any terminals, references, locals or property nodes in it. For example, you have a subVI which uses a references to change the blinking property of the Pilot boolean.

[asbo]

I thought it was a little weird to have a display loop, but I'll admit I don't commit too much to design patterns. Producer-Consumer-Display seems like its beginning to encroach on Model-View-Controller, but in a different order.

I'm not sure why P-C always seems such a popular choice for practice problems. It's one of the most obvious patterns, I suppose, but I agree that the problems are not necessary apt to it. I think a queued state machine (waiting for Daklu to swoop in ...) would have been my inclination here. K.I.S.S.

In any case, for P-C-D I would put all control terminals/references in the producer, none in the consumer, and all indicator terminals/references/property nodes in the display. Control property nodes could probably go in the display loop as well, depending on which property they dealt with. In general, I avoid Locals.

[jgcode]

In general, I avoid Locals.

Whats wrong with locals?

I usually prefer them over references to update a control.
However, I the rule I use is: one per control on each diagram (in the case of e.g. a state machine).

[asbo]

Whats wrong with locals?

I usually prefer them over references to update a control.
However, I the rule I use is: one per control on each diagram (in the case of e.g. a state machine).

Generally speaking, I feel that if I have to use a local, things may not be structured well. Typically, I keep my actual data disconnected from the FP. If it's a control we're talking about, I use an event to update internal state data and then reference that where necessary; if it's an indicator, internal state data will occasionally be pushed to the front panel. I use locals over property nodes if I don't need to enforce execution order, but to be honest, everything has its place. I didn't mean to hate on locals, necessary, but they just leave me feeling icky.

I expect that you still bend or break your rule, though... That's what rules are for.

[Daklu]

I think a queued state machine (waiting for Daklu to swoop in ...) would have been my inclination here. K.I.S.S.

*flap* *flap* *flap*
Did somebody say QSM?


Actually the CLD is one of the few places I do recommend using QSMs. The exam problems seem to be designed for it and the code is thrown away after its graded. There's no concern for creating a sustainable application and putting time into architectural concerns takes time away from the things that earn points.

[jgcode]

Typically, I keep my actual data disconnected from the FP. If it's a control we're talking about, I use an event to update internal state data and then reference that where necessary; if it's an indicator, internal state data will occasionally be pushed to the front panel. I use locals over property nodes if I don't need to enforce execution order, but to be honest, everything has its place. I didn't mean to hate on locals, necessary, but they just leave me feeling icky.

I do the exact same thing - separating data from UI.

I just like don't have issues with using locals to update a control when it comes time to push state data to the FP.

I expect that you still bend or break your rule, though... That's what rules are for.

There is one particular use case where I use them for the wrong reason but it's hidden - but yes you are right! However, normally I don't and don't need to break that rule

[Daklu]

I just like don't have issues with using locals to update a control when it comes time to push state data to the FP.

Agreed. Local variables in and of themself aren't bad... I use them frequently in my fp display loop.

Typically, I keep my actual data disconnected from the FP. If it's a control we're talking about, I use an event to update internal state data and then reference that where necessary; if it's an indicator, internal state data will occasionally be pushed to the front panel.

This is the important thing to remember. Indicators and controls are ways for users to see and change the internal state data--they should not be used to store the state data. As long as I follow that rule I haven't had any problems with local variables.