timer with separated input settings

[Blokk]

Hello,

The idea with this timer is that, I would like to be able to set the different parameters of the timer independently of each other, and from any location of the main VI.

So I have enum cases for every settings (and the reset case sets multiple inputs of course), and independently of the actual operation mode, I can check any parameter value.

What do you think of this implementation?

Regards,

ps.: I know I should not mix the control/indicator design (silver, etc.), I will unify them later.

[Blokk]

and almost forgot to mention, I used one of J. Bohrer's example as starting point, as you see in the doc part of the VI.

And I forgot to make the input terminals non-required, since this is not the way for such action engine.

[Blokk]

I did not like that I have 6 shift registers in the timer, so I reduced it to 4. In order to make this reduction, I needed to add a parameter cluster however...

I also did not like the behaviour when the timer was in elapsed time state, but paused, the autoreset activation triggered a reset. Now if the time is elapsed, and the FGV is paused, the autoreset value change only get stored in the cluster shift register, but does not trigger reset.

So here it is:

edit: I guess for CLD, all the controls and indicators should get documentation? But I guess tip strip is not necessery for subVIs, only for the visible VIs, which the user can see?

[JÞB]

Keep going!

You mentioned sone design considerations.......What was the thought process?  Actually, I agree mostly with the result but, question if they are relevant to the "In 4 Hours" spec.

The "Thought Process" will help us help you be letting us in you head.  

Or, just sit the exam!  You seam ready.

[Blokk]

Actually I am already at the middle of the CLD prep material, and after that I want to practice the 4 test full exam, and see how I can handle them, and with what speed 🙂

The above FGV does not connect to any scenario, I just wanted to practice a kind of "general" solution, so I can make the above FGV in a few minutes from scratch. This FGV can be handy if I need to alter any state of the timer from my main VI independently, and also I can read out any state info. In this way I may avoid shift registers in the main VI's state machine (either if it is a simple state machine, or more advanced structure).

Naturally if the spec needs only a simpler timer lets say without even pause function, I can just throw an elapsed time express vi in a FGV to make it non-reentrant and it may be faster.

Exactly 3 weeks from today I have the exam, I just really have to speed up 🙂

[JÞB]

OK,  spend some time on "File I/O too"

Every exam will have a timing element-- They will also heve a file read/ write req!

there  are basically three elements for CLD

Can you understand timing?

Can you understand File IO?

Can you understand design patterns?

OH! and can you use "Tip Strips" to communicate with the "User?"

Nervous is a good thing.  The exam WILL challenge you!  (or, you are a much more experienced programmer than I)

[Blokk]

---

@JÞB wrote:

OK,  spend some time on "File I/O too"

Every exam will have a timing element-- They will also heve a file read/ write req!

there  are basically three elements for CLD

Can you understand timing?

Can you understand File IO?

Can you understand design patterns?

OH! and can you use "Tip Strips" to communicate with the "User?"

Nervous is a good thing.  The exam WILL challenge you!  (or, you are a much more experienced programmer than I)

---

Believe me, I WILL be nervous 🙂

I have already went through File I/O part, and yes, parsing info in and out can be time consuming to build it up...

About the design patterns, I hear people saying always (including NI instructors), that 99% of the given exam scenarios can be solved with simple state machine polled at 100 msec (or maybe 50 msec would be better, just to stay safe inside the responsiveness margin at 100 🙂 ).

Actually I will need to examine deeper the 4 example projects to see other scenarios. As I remember, in the case of the ATM machine, a user interface event handler template is better. So if i am not in a mistake, the state machine was in the Event handler loop.

I remember there was a kind of flowchart during the Core 3 online self-paced training, explaining what kind of design to choose for different cases. It was not really clear to me, I wonder if there is a white-paper doc or something you know about which explains it better...? 🙂 

[crossrulz]

I fully believe the simple state machine will do 99% of the CLD exams out there.  At least all of the ones I have seen could be simply done with a state machine.  One of the keys to keeping it all in a single loop is to make sure you have an "Idle" state.  That Idle state should have your event structure with a timeout.  Then make sure you are going to the Idle state every so often in your state sequences to make sure you are responding to the user.

[Blokk]

---

@crossrulz wrote:

I fully believe the simple state machine will do 99% of the CLD exams out there.  At least all of the ones I have seen could be simply done with a state machine.  One of the keys to keeping it all in a single loop is to make sure you have an "Idle" state.  That Idle state should have your event structure with a timeout.  Then make sure you are going to the Idle state every so often in your state sequences to make sure you are responding to the user.

---

Thanks for the hint!

To have an Event structure inside one case of a case structure (inside a while loop which "holds" the shift register, so the states, etc) just makes me feeling uncomfortable, but I guess this is the way how to get fast through the CLD 🙂

I understand that, if we can be sure about that every other case executes in less than 100 msec, than we are safe...Hopefully the user cannot click on two different command button on the GUI in 100 msec, in this case this structure would blow...would not it?

[crossrulz]

None of your other states should take long to execute.  In long I mean in miliseconds.  So the 100ms requirements should not be an issue.

Where you could possibly see some interesting things is in the delay sequence.  You should let the Idle state do your waiting and then check to see if enough time has passed.  You can bounce back and forth between the Idle and the Check Timer until the time is up and then proceed to the next step in you sequence.  This will let you response instantly to a user.