CLD Car Wash Car Postion Slider Question

[JJeremy]

Hello,

I’m preparing for the CLD and was working on the Car Wash problem.  When all wash steps are complete, the program is supposed to wait until the Car Position Slider moves into the Exit position, then, per the instructions, “all Car Wash Indicators should turn OFF and the Car Position Slider should reset to the Entry position.”  What I’m noticing is that depending upon the speed of the mouse click, it seems that the Car Position Slider may not get updated to Entry on the front panel.  I have experimented with adding a delay in the “Exit” case right after the car position slider is moved to Exit.  50 ms is not a long enough delay for the FP to update while 200 ms is (for a quick mouse click).  Is this just a matter of the mouse button timing between the mouse down and mouse up occurrences?  Does the Car Position Slider continually update while the mouse is clicked down (in this case to a value of 4 for the Exit case)?  I’ve tried holding down the mouse and observing the Probe Watch Window. The Property Node in the Init case will eventually override the 4 from the mouse down to 0.  Experimenting with Local Variables in place of Property Nodes did not seem to make a difference.

The Labview provided solution to this has similar issues with updating the Front Panel Car Position Slider on a long mouse click.  Any thoughts on this is greatly appreciated.

Thank you,

Jeremy

[altenbach]

I cannot open your project on my curremt computer. Consider "save for previous" (2020 or below) before attaching so more can look at your code.

[JJeremy]

I've saved the project the Labview 2020.  Please let me know if you can't open it.  Thanks, Jeremy

[altenbach]

I am not sure if you got a template, but the position slider should probably be an indicator. The user should never operate it directly.

Can you be a bit more specific how to reproduce the problem? What are all settings and how do you operate things and in what order? At what point in time does the problem occur?

On a side note, personally I would give deductions if front panels and diagrams are maximized to the screen. Nobody likes to stare a 90% whitespace while being prevented from looking e.g. at the help window at the same time.  In the timer I would use "high resolution relative seconds" instead of a timestamp converted to DBL.

[SSSchroeder · Accepted solution]

The question is more about understanding the behavior of the slider than the CLD task itself. Maybe this is a simulation where you are using the slider to "move" the car from station to station. The observation is that when you move the slider to Exit, the process appears to reset, but the slider doesn't move back to Entry unless some delay is added before the Init case runs. 

I made a simplified example. Run the code & click 4 on the slider. You should see the LED light up indicating the value DID get reset to 0, but the slider will still be on 4. 

I think it's just a quirk of these controls because they "live update" the value as you move them. The value IS getting reset in the Init case, but since the mouse is still down, the slider immediately snaps back to the mouse position. I don't know of any way to change that behavior. It would be nice if there was an equivalent to the "Update value while typing" property that exists for string controls. You could probably restructure things to work around it. For example, waiting on a mouse up event before resetting the process.

 

[SSSchroeder]

Didn't realize snippets were a problem. Here is the VI.

[altenbach]

---

@SSSchroeder wrote:

The question is more about understanding the behavior of the slider than the CLD task itself. Maybe this is a simulation where you are using the slider to "move" the car from station to station. .

---

In the car wash example, the slide is used as a status indicator controlled by the program. It should never be operated by the user. Either make it an indicator or disable it.

Snippets are not a problem but they can only contain simple code. For example if the "state enum" is a typedef (as it should be!), it won't be included, breaking the snippet code when placed on a diagram.

It is always a bad idea having the user fight with programmatic changes of a control, too many cooks! I am not sure why your demo needs to waste my laptop battery spinning the loop millions of times per second burning through the CPU, but it does not solve the original problem, just shows how not to do it. 😄

[JJeremy]

The Car Position Slider was given as a Control in the given Template.  Also it suggests in the exam wording that the user would simulate travel.  I don't believe we are allowed to change a Control to an Indicator on the exam.  Can you confirm?

SSSchroeder's VI did summarize my core question: When you have user and programmatic changes fighting for control, is there a good way to officiate?  I get that the preferred option is not to do it.  However, when forced to, is there a good way to minimize problems?

[altenbach]

Do you have the full requirements document for this example?

This is ambiguous:

You can make it a fake indicator by just disabling it so the user cannot control it. A car was is an automated process  where it goes through the initially selected stages and the slider shows what it is currently doing. Trying to operate the slider is similar to climbing into the car wash and trying to manually push the car forward or back against the will of the programmed sequence. Seems silly to me. 😄

[JJeremy]

Attached is the PDF that accompanies the Exam (downloaded from NI).  My guess is the control is meant to simulate the car pulling forward.  Maybe I'm misinterpreting it.