CLD Boiler Problem: How Did I Do?

[Mathis_B]

If you had managed to get the first definition rhyming as well I would have splashed out a Kudos 😛

[mattmunee]

---

@JÞB wrote:

  If you change the order of your cluster (or your cluster inside your cluster), then you'll need to change the case structure. 

---

Not with unbundle by name;)  The order of the cluster can change at any time and the names stay in the same order out of unbundle by name.  

For clarity the two functions should probably have been called "unbundle by cluster order and break my code" and "unbundle by name to keep me sane"

---

I may be missing something, but in your example, you used an unbundle to separate a sub-cluster and a boolean.  Then that sub-cluster was run through a cluster-to-array block and all names are lost.  If you changed the order of the sub-cluster, you would need to change the case structure.  I guess you could unbundle each sub-cluster element by name, then build the array, but this is still messy.  What if your cluster contains 30 items?

Are any of you aware of any discussions about allowing the Event Structure's "new value" terminal to count as a read operation that would trigger a boolean latch?  Even after all this talk, I'm still leaning towards replacing the latching booleans with switched booleans and then changing the value back to its original value in the event structure using a value property node.  I know everyone's against those things, but it's more modular, scalable, and clean when considering this as an alternative.

[JÞB]

---

@mattmunee wrote:

---

@JÞB wrote:

  If you change the order of your cluster (or your cluster inside your cluster), then you'll need to change the case structure. 

---

Not with unbundle by name;)  The order of the cluster can change at any time and the names stay in the same order out of unbundle by name.  

For clarity the two functions should probably have been called "unbundle by cluster order and break my code" and "unbundle by name to keep me sane"

---

I may be missing something, but in your example, you used an unbundle to separate a sub-cluster and a boolean.  Then that sub-cluster was run through a cluster-to-array block and all names are lost.  If you changed the order of the sub-cluster, you would need to change the case structure.  I guess you could unbundle each sub-cluster element by name, then build the array, but this is still messy.  What if your cluster contains 30 items?

---

If I need 30 uniqure commands to a single QMH, each selectable by independant control value change in a single cluster they would rip my CLD polo off my back  

But, that's not how a boiler simulator works and, you have four hours as a hard requirement.  This is NOT the "General Construct of the Everything GUI"  That takes much more than four hours.  You have a defined cluster that you were required to use and failed to implement a solution that met the req.  Solutions that do meet the req are possible, as I demonstrated, although they introduce some maintenance challenges.  Comments like "To the next developer: Don't blame me see REQGUI000123" will help them understand why they should not hunt YOU down.  You will often find really odd requirements that require "less than ideal" software choices.  I've seen some that made me throw up just a little in my mouth. 

[mattmunee]

---

@JÞB wrote:

---

@mattmunee wrote:

---

@JÞB wrote:

  If you change the order of your cluster (or your cluster inside your cluster), then you'll need to change the case structure. 

---

Not with unbundle by name;)  The order of the cluster can change at any time and the names stay in the same order out of unbundle by name.  

For clarity the two functions should probably have been called "unbundle by cluster order and break my code" and "unbundle by name to keep me sane"

---

I may be missing something, but in your example, you used an unbundle to separate a sub-cluster and a boolean.  Then that sub-cluster was run through a cluster-to-array block and all names are lost.  If you changed the order of the sub-cluster, you would need to change the case structure.  I guess you could unbundle each sub-cluster element by name, then build the array, but this is still messy.  What if your cluster contains 30 items?

---

If I need 30 uniqure commands to a single QMH, each selectable by independant control value change in a single cluster they would rip my CLD polo off my back  

But, that's not how a boiler simulator works and, you have four hours as a hard requirement.  This is NOT the "General Construct of the Everything GUI"  That takes much more than four hours.  You have a defined cluster that you were required to use and failed to implement a solution that met the req.  Solutions that do meet the req are possible, as I demonstrated, although they introduce some maintenance challenges.  Comments like "To the next developer: Don't blame me see REQGUI000123" will help them understand why they should not hunt YOU down.  You will often find really odd requirements that require "less than ideal" software choices.  I've seen some that made me throw up just a little in my mouth. 

---

Jeff, understood.  I guess I need to get used to just following orders, but this is a very unsatisfying conclusion.  Looking beyond the CLD exam, I have an empty feeling inside. 

P.S.  Do you actually get a CLD polo!?!?!?!?

[crossrulz]

---

@mattmunee wrote:

P.S.  Do you actually get a CLD polo!?!?!?!?

---

My CLD is old enough that it is an ugly brown button up shirt.  They have since changed to a dark blue polo (which is what my CLA polo is).  New certifications should be a nice lighter blue.

[JÞB]

Yes, Seen here

[crossrulz]

---

@JÞB wrote:

Yes, Seen here

---

Warning...blindness my occur due to seeing Jeff's mug.

So Jeff, why isn't it a nice light-blue CLA shirt?

[JÞB]

---

@crossrulz wrote:

---

@JÞB wrote:

Yes, Seen here

---

Warning...blindness my occur due to seeing Jeff's mug.

So Jeff, why isn't it a nice light-blue CLA shirt?

---

Its on the COE plan.....Stay tuned- I've got some time.

[mattmunee]

---

@Mathis_B wrote:

[...]

I see a potential problem whenever you do a purge. The purge is handled within the states (always the same code why not use a subVI???) and with that blocking the queued state machine for 10 sec which is a violation of the requirement that the application has to be responsive within 100ms (that's a biggy).

Personally I would have liked to see you showing the ability to modularise code by using subVIs which will likely get deductions in style.

[...]

---

I'd appreciate your look at my second attempt to address the purge states.  You're right; that's a big no no.  Please see how this was handled in "Boiler_v2.vi".  I'm not necessarily concerned about the documentation here, but I'd like some feedback on my style and functionality, specifically for the "Pre-Purge" and "Shutdown" states.  They now perform an asynchronous call to a timer VI.  I'm worried it may be a bit overkill to use the scripting pallette for this.  Maybe you can provide insight into a simpler solution that would still work with the queued state machine?

[Mathis_B]

Yes, I think that might work but I would consider it overkill to the extent that you might get deductions for hopelessly overcomplicating the problem.

There are several possibilities. One would be to have the state come around to itself and check if the time has expired. If yes go to finished state if no come back:

another option would be to create a timeout on the dequeue and handle timing in a timeout case. For that I would wrap the dequeue in a subvi:

In the timeout state you could then use a timing action engine as practiced in the CLD prep excercises