Cluster not response to event.

[KateB]

Hi all,

I'm preparing for CLD, and find a problem with ATM simulator exercise as shown in attached file.

Please follow below steps to reproduce this problem.

1. Extract files.

2. Open atm.lvproj, and run main.vi.

3. Press card simulator to activate user input.

4. Put 12345 in user input, and press enter.

5. Left, and right menu will show its function, and you should be able to press left, and right buttons, but they don't response to your interaction.

If you've any idea, please kindly share it.

Please note that I use LV2010, but I downgrade my code to 8.5 so that we can share it more.

Regards, Kate

[RavensFan]

I don't have LV on my PC right now to be able to open your files.

But from your description, my guess is that you have an event set to "Lock Front Panel until event completes" and that it is blocking you from further interactions with your front panel.

[TCPlomp]

The basic issue is that your code doesn't default to the event case.

Is it by design that the time-out of the event structure (10 seconds) terminates the program? What happens if someone is low in entering there details?

Ton

[altenbach · Accepted solution]

There are serious problems with dataflow doe to poor choices of program design.

You should never have event structures inside case strctures, especially not several event structures, each in a different case of the same case structure. Event structures are not dataflow driven, so they queue up events even if there is now way of servicing the event due to dataflow issues. Your events are set to lock front panel until the event completes, thus any event that cannot be handled by the program will lock up the front panel forever.

So: Get rid of the case structure and use a single event structure with multiple event cases. That should be all you need. The event structure should be directly on the diagram of the while loop. Simplify! Put your case structure inside the single timeout case and modulate the timeout duration via a shift register if needed.

A good tool is also execution highlighting. Operate the VI while watching the diagram in slowmotion. You'll see where it gets stuck.

[altenbach]

Also use some more intuitive labeling in order not to confuse the next guy that will inherit and maintain the code. For example don't label a boolean diagram constant as "Continue program" where TRUE actually means "Stop" and FALSE means "continue".

That's backwards and confusing!

[KateB]

Thank you all of you for the help.

I decide to go for single event structure approach and remain only operate state event structure.

It solves the problem.

Please refer to attached file for my solution.

I may post back to this thread again for other 3 exercises to go.