CLD example for comments

[Sreedhar_T]

Dear all, We are a bunch of ppl who want to appear for CLD exam shortly. We took the "Sprinkler Controller" example and tried to complete the same in the stipulated time of 4Hrs. PFA the "SprinklerController_For_Forum.zip".

Although some of us fared well in the exam some are still in need to improvise on the coding speed (which seems like impossible now ).

I'm posting the question and the example (LV 8.6) in this forum to get your comments and feedback.

I'm sure a lot active participants like me will definitely share their experience and comment the way we coded.

Thanking you in advance.

Sreedhar.

[JÞB]

Not quite!

A few positives first:

1. The Block diagrams are fairly clean and readable with some good comments
2. The user controls all have tip strips.
3. the FPs are nicely arranged
4. the Incon and connector panes are clean

Now the not-so-goods.

the overall archetecture was a poor choice.  For instance if the operator selects "rain" while zones are in service the enevt is missed until the next time the top SM is in wait.  BIG trouble with UII responsiveness and well- you completely miss the requirement for displaying the RAIN status and interupting service. 

leaving the state with a running event loop is just poor programming practice.  leave the event loop running to handle events and queue commands to another machine to react to the events. 

The use of user events as a queue method limits you to enqueue and dequeue in order- had you selected a straight Queued producer comsumer (events) template high priority events (like rain state change) could have encueued at opposite end ar (like stop) flushed the queue befor enqueuing the next command.

the arrays of strings of state machine states would be better as enum type defs- just a whole lot easier to maintain.

the use of abort execution should be avoided

It might have been a good idea to allow the setup to write new values to the setup file.

A bit more practice (and seleting the right archetecture will help the speed)

[Sreedhar_T]

Hi, highly appreciate your feedback. Just realised that the required functionality has not been completely implemented...

but we thought that the architecture we have selected is something we could proudly brag about... but now I think we need to rework from the basics... 😞 would you let me knw the drawbacks of this kind of architecture?

one thing I can list is, its a bit time consuming...

[JÞB]

Well,  you are not the first person to struggle with event structure usage!  Here is a quick demo that you can play with that exposes some of the "features" you wrote into your example.

In the top loop you can see all the code.  the lower loop contains a Stop Val change event with a True wired to the lower bool tunnel and the false case of the case structure contains a wait.vi wired from mSec 3 and negates the boolean on the top SR.

First, relying on TMO for acurate timing in your example is bad.   If you watch the top loop run you'll see that the loop starts, the Event structue sees that 1000mSec TMO constant and starts waiting for events.  1000mSec later no event is seen so a timeout is generated and the timeout case is executed.  then bool 1 flips and mSec time later the event case exits and the loop iterates.  with mSec = 1000 bool 1 flips every 2 seconds.  Esentially the tmo is reset each time the loop starts so any code outside the event strucure or in other cases creates a timing uncertainty.  Your example suffers from this effect and the zones are not correctly timed.

Next, What happens if the stop button is pressed while the lower loop is waiting in the Timeout case?  Since the event structure isn't ready to handle the Stop Val change event the loop must first exit the timeout case and the case structure and the loop must iterate with a TRUE in the top Shift register to get back into the True case and start waiting for events.  However the event Stop Value change is already on the event queue! the event happened! so the Stop val change case executes.  but with up to mSec 3 + mSec 2 delay after the event occured.  two issues here a long executing event case blocking the handling of another event and an event structure inside a state machine. both no-nos since the state machine may NEVER re-enter the state that looks at events. (in the demo remove the negate in the false case and you get a infinate loop! )  There is a requirement to handle user input in a timely fashion that you miss in your example because your events are blocked for these reasons.

Third, (but not seen in the example above) your example mixes event queues and the state machine queues (the arrays of strings)  the user events and the FP events can only be handled 1 at a time and ONLY after the state machine returns to the event handeling case.  with both loops generating events for the other (and FP activity joining the event queue) you can (and have) created a debuging nightmare since the delay between when an event is generated and when it is serviced is totally unkowable and dependant on what else happened. 

In conclusion the event structure is very useful for executing code in response to FP activity (and programatic events) and no other structyre easilly allows a break from dataflow to event processing BUT< we should chose the right tool and use it correctly.  Use events to monitor programatic states and other asynchronous elements (like Users pressing buttons).  DO NOT execute lengthy code inside an event because it blocks other events.  DO NOT put event structures inside case structures or state machines (unless all events are dynamically registered and you unregister before you leave the state.  there are time this is useful)  DO NOT rely on the timeout case for critical timing.

Look into some of the examples that use the PC loop (events) template. and the Help file for more information and you are getting there!

Keep slinging wires!

[Kathireson]

Hi,

Thanks for your comments. But i would like to mention a few points for the comments you have given.

you said:

 " DO NOT put event structures inside case structures or state machines (unless all events are dynamically registered and you unregister before you leave the state.  there are time this is useful)  DO NOT rely on the timeout case for critical timing"

    We have used this architecture in our project, ( its a large project with around 2000 signals ) and never found any problem with this architecture. We are even able to acheive a tight 20ms Timing requirement. We did this only with the timeout functionality of the event structure.

But i'm still not convinced with NOT using event structures inside state machines. The drawbacks you mentioned can be avoided by selecting a design which always returns back to the state which has the event structure, and using a producer consumer pattern to prevent the locking of front panel.

By using the Event Structure within a state machine allows us to create a common design which can be used in a layered architecture, where my VI will be able to listen to Front panel Events AND/OR programmatic events and execute the states in an order. ( for situations where more than a single received event needs to be retrieved we use an additional queue )

It actually came as a surprise to us, that you completely rejected the design. We found the deisgn easily adaptable to different requirements.