Certification

cancel
Showing results for 
Search instead for 
Did you mean: 

ATM (100528-01) LV2013 solution error?

Solved!
Go to solution

Hi All,

 

I'm just going through the solution and I spotted the following:sample.png

 

As you can see, when the consumer loop is exiting it call the producer telling it to exit.  The producer runs it's exit case which calls the consumer loop again even though the consumer should have stopped. 

 

I certainly wouldn't code something like that intentionally but maybe I am missing something vital, is that an error in the solution or have I read the logic wrong?

0 Kudos
Message 1 of 7
(3,934 Views)

The producer loop doesn't "call" the consumer loop, it just enqueues a new states towards the consumer. If the consumer loop canoot dequeue then it just doesn't...

Both loop condition terminal is wired to a TRUE constant so they both stop immediately.

CLAMaxime -- Kudos are a great way to say thank you
0 Kudos
Message 2 of 7
(3,911 Views)

What if the consumer loop stops? This could happen in the case of an error. If you don't have the consumer loop firing the event for the producer, then the VI "hangs". 

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 3 of 7
(3,907 Views)
Solution
Accepted by topic author SeanJ

If I am not mistaking, in this sample exam any error generated in a consumer of any module is handled that way: the concerned consumer enqueues a new state in the Error Handler module queue. Once dequeued, that state fires a user event so that every module generates its dedicated exit procedure.

 

I get your point Fabiola but from what I see here, it is OK. It may not be the best way to achieve that but it should work. Once again I may be wrong and I would be happy to get some explanations if that's the case 🙂

CLAMaxime -- Kudos are a great way to say thank you
Message 4 of 7
(3,903 Views)

Create a project using the National Instruments Queued Message Handler and study how they exit the application. You will see it is the same approach.

 

 

For an opportunity to learn from experienced developers / entrepeneurs (Steve, Joerg, and Brian amongst them):
Check out DSH Pragmatic Software Development Workshop!

DQMH Lead Architect * DQMH Trusted Advisor * Certified LabVIEW Architect * Certified LabVIEW Embedded Developer * Certified Professional Instructor * LabVIEW Champion * Code Janitor

Have you been nice to future you?
Message 5 of 7
(3,896 Views)

Thanks Fabiola/ Maxine,

 

I don't know how I didn't spot the fact the consumer 'Exit' case is not calling the producer, maybe more sleep required!  It doesn't really make sense to me that the exit case would fire an abort user event when the error handler should be generating the user event.  I'm still trying to get my head around this architecture! 

 

So in summary, the error handler will tell producer to stop via the error handler but a situation where the consumer loop fails might cause the system to hang. 

 

Many thanks,

Seán  

0 Kudos
Message 6 of 7
(3,867 Views)

Actually, this may be the reason why I was confused:

 

call close.png

 

As you can see in the above, the consumer and the user event  is called by the controller (looks like a type of race condition).  This means the consumer could then call the user event which would then call the consumer that had already stopped.

0 Kudos
Message 7 of 7
(3,855 Views)