State machine

[cl0ck]

I didn't think about dynamically setting the timeout, thanks!

It works, sort of. I've encountered an odd bug in my program - after making the changes you proposed, the VI works like  a charm.

But only once.

If I hit 'Exit', then run the VI again, the second loop ("continously acquire) will only run once, then hang. Suddenly the new timeout value isn't being fed into the Wait on Notification...

And another, unrelated question - When I'll 'read' the values acquired, I'll only need the latest one read, and don't care about the history. So if I am going to use a queue, it will be quickly filled with unqueued elements. Can a queue be 'too full' (memory issues)? If I only need the latest value and don't care about the history, is it better to use notifiers or does it not matter?

Thanks again for all your assistance

[cl0ck]

OK, I figured it out, stupid mistake - in the "Exit" state of the first loop, I use a property node to change the state of the boolean controller wired to the stop condition of the second while loop. However I forgot to turn it back to 'off' when the program restarts.

[crossrulz]

---

@cl0ck wrote:

OK, I figured it out, stupid mistake - in the "Exit" state of the first loop, I use a property node to change the state of the boolean controller wired to the stop condition of the second while loop. However I forgot to turn it back to 'off' when the program restarts.

---

Instead of setting a control value to stop your second loop, why not make a command to do it?  I would change your notifier to be a queue with a data type of string.  From there you can easily pick up a "Stop" and stop your loop.  On a timeout, do the acquisition.  Your other commands can be "Start Acquire" and "Stop Acquire".

[ohiofudu]

cl0ck,

Ok I got it working.Here is the Code.If you have more Question kindly post your Code again.

[DailyDose]

I'm not sure I understand why, at this point, you're not using Producer/Consumer.  To me this would seem to make more sense to use to mimic data acquisition and still have UI.

Unless of course the only thing the slave loop does is acquire data.  Then... I guess nevermind.  I don't know, what do the professionals think about master/slave vs producer/consumer?

[crossrulz]

---

@ohiofudu wrote:

---

The problem with this code is when the command to stop is sent.  Here's the scenario I'm afraid of:

1. You read a TRUE from the Notifier.

2. A command is sent to stop acquisition (FALSE).

3. You into the case structure in the consumer loop and set the notification to a TRUE.

You just caused a problem.  That FALSE was never recieved since the TRUE overwrote it.  This is one of the reasons I do not have a consumer enqueue commands to itself.

Also, what happens if there is no notification and the Exit button is pressed?  The loop will not stop until it receives a command (likely 2).

[crossrulz]

---

DailyDose wrote:  what do the professionals think about master/slave vs producer/consumer?

---

Rarely do I use Master/Slave.  Nearly everything I do needs every command sent to it.  Therefore I use Producer/Consumer with either queues or user events.

[ohiofudu]

crossrulz,

Talk is cheap.Let see your solution(Code).I was just playing with the original Code.

[billko]

---

@ohiofudu wrote:

crossrulz,

Talk is cheap.Let see your solution(Code).I was just playing with the original Code.

---

We're all on the same team, right?  Maybe you should rephrase your statement...

This is not a confrontation - it's a learning experience.

[crossrulz]

---

@ohiofudu wrote:

crossrulz,

Talk is cheap.Let see your solution(Code).I was just playing with the original Code.

---

No need to be hostile.  I was just pointing out some things to be careful of.  Just quickly made this from scratch with my 1 year old climbing all over me, so it is likely far from perfect.

I'm just using the timeout to allow for the acquisition to happen at a normal rate.  The top loop can send a Start, Stop, or Quit command at any time and the second loop will respond nearly instantly.

Also note that I destroy the queue in the "Quit" case of the consumer loop.  I hate stopping consumer loops by looking for the queue to be destroyed.  I always lose data that way.