Advice for communication using multiple consumer loops

[mcduff]

I think you should try with the JKI template, with a single loop. If you cannot master that, then multiple loops will be difficult. Attached is an example to get you started. You need the JKI template for it to work, download from VIPM.

mcduff

[atrinh]

I have taken a look at the JKI template and as previously mentioned, I would still like to work with the basic architecture that has multiple loops. I've seen a lot of vi's in the forums with a similar set up, so this can't be an incorrect set up especially for someone tackling architercture like this for the first time. I also find it easy to follow and implement, especially if I using the Highlight Execution function. Once I understand how to successfuly run this program, I think the JKI template will make more sense to me.

I would really like some feedback on what I might be doing wrong that is preventing me from seeing data live on a graph control during acquisition. I have used probes to determine if the Producer Loop and Display Loop are in the same states, and they are. They have separate message queues but this information seems to be passing correctly because I am getting a display of the data on the graph AFTER the acquisition stops.

Thanks for all your assistance so far.

[mcduff]

I have taken a look at the JKI template and as previously mentioned, I would still like to work with the basic architecture that has multiple loops. I've seen a lot of vi's in the forums with a similar set up, so this can't be an incorrect set up especially for someone tackling architercture like this for the first time. I also find it easy to follow and implement, especially if I using the Highlight Execution function. Once I understand how to successfuly run this program, I think the JKI template will make more sense to me.

Did you try the example I sent?

Highlight execution works for any VI, even the JKI State machine.

Multiple loops are fine, but are extremely hard to debug, especially for a beginner. That's why a single loop State machine was recommended.

If you cannot make sense of the single loop system, not sure how you will be able to handle multiple loops.

I would really like some feedback on what I might be doing wrong that is preventing me from seeing data live on a graph control during acquisition. I have used probes to determine if the Producer Loop and Display Loop are in the same states, and they are. They have separate message queues but this information seems to be passing correctly because I am getting a display of the data on the graph AFTER the acquisition stops.

What's diffferent/interesting/strange about your architecture is that you are sending the same command to all loops all the time. In my systems I may have an "Instrument Loop". I send a command to it to get data, then from the "Instrument loop" I send a command to the "Display Loop" to update the display. Think about how you want your loops to respond.

It looks to me like you are placing your data in your writing queue, not your display queue. That may be the reason your display is not updating.

mcduff

[udka]

For making it to simple to debug let's limit to three loops and exclude the writing loop.

-Give names to identify the wires for queue instead of unnamed to distinguish between queues.

-To display loop you are enqueuing data from State machine producer loop which is happening the same as you are doing isn't it? Hence first data indicator in producer will display and after that LVDT in display loop.

Edit: @mcduff, there are four queues, two which enqueue data in acquistition state and other in calibration state. Now in each set one is for display and other for write. The thing is enqueue of data is happening in producer loop which means after which only data in display loop is displayed isn't it?

[atrinh]

-Give names to identify the wires for queue instead of unnamed to distinguish between queues.

Yes I agree I should have put names to identify what queues are. I've corrected this.

-To display loop you are enqueuing data from State machine producer loop which is happening the same as you are doing isn't it? Hence first data indicator in producer will display and after that LVDT in display loop.

From how I understand it, what I have tried to code is when we are in the state where the DAQmx Read is operating, it is inserting into 2 queues (one for display and one for writing) a 1D DBL 1Chan NSamp. The display loop should be in the same state and should be (or at least this is what I want) dequeing from the Display queue. This is why I thought it should display as the data is being collected but I think I am doing something wrong...

The thing is enqueue of data is happening in producer loop which means after which only data in display loop is displayed isn't it?

You've made an edit to a comment I made but I am not sure I understand what you are saying here. Could you clarify please?

Thanks for your help.

[atrinh]

Thanks for taking the time to explain things.

I have opened the JKI template and poked around - I quickly became lost in the Parse State subvi with the state and args, which is why I am having a hard time understanding how this template works. I also checked out the hyperlink provided in the vi but can't find any details about the JKI state machine on the website. With my current set up, I can visually see how each loop is responding to my message queue (I have 3, 1 for each loop of producer, display, and write) so I have had an easier time figuring out what I have erred on in the past.

What's diffferent/interesting/strange about your architecture is that you are sending the same command to all loops all the time.

Yes I am sending the same command to all loops at the same time. I thought this is how I would get my loops in the same state. For example:

- producer loop is setting up a DAQmx task

- display loop is locking front panel controls so user can't change parameters used for setting aforementioned task

- writing loop (if user decides to save data) would set up a file and write a header.

It looks to me like you are placing your data in your writing queue, not your display queue. That may be the reason your display is not updating.

I checked this and I am looking at the write queue actually. I just have the wrong label and used udka's suggestion of labelling my queues. You'll notice the top 2 queues are actually display and write for 2D array while the bottom 2 queues are display and write for 1D arrays

[udka]

Please clarify me on this:
-Is the display loop is in proper state as expected, but display loop is running slower or updating slower?
-Why is there a wait for 100ms in display for lower calibration?

- I maybe misunderstood by this "The program will collect data but only displays it after the collection has ended. I assumed you are explaining about the Producer loop."http://forums.ni.com/t5/LabVIEW/Advice-for-communication-using-multiple-consumer-loops/m-p/3350987#M...
-Could you clarify bit more if i didn't understood it correctly?

[atrinh]

Yes the display loop is in the expected state - it transitions to "Lower Calibration" right after the Producer loop switches. I am not sure how to tell if my loop is running slower (than producer?) or how slow

The Wait 100 ms was a missed item that doesn't belong there. Accidentally copied that over.

To clarify your last point, when I start my calibration, it begins to collect data and I can see the producer loop has switched to a "Lower Calibration" state. When it is finished and returns to "wait for user input" the display loop updates the graph with the 2 seconds of data acquired from DAQ board. So I know it is collecting something but it appears it iswaiting for the producer loop to go back to idle and then it updates. Sorry if I confused you.

Thanks

[udka]

I think i get it now, are there any events happening in between Low calibration and it goes to  wait for user input state?

Edit: If i misunderstood please explain the sequence of events bit more?

-to make it more sequenced after enqueing go to case structure and enqueue next state.

-immediately after that you are making the Stop Low cal and then wait even then it should be fine when you remove wait also still experiencing the issue?

[udka]

Edit to my previous post:

-The data you keep on inserting into array, isn't it you should reset when it enters stop low cal state?

-the shift registers which you initialized are not actually empty(some four elements are present with 0s)

-In your change state.vi there is no need for index array in for loop you can use auto indexing from Array of States.

-I didn't see where you are enqueuing the exit state(where is exit button and event handling for that?)

-What happens if the daqmx task is not done?(are you sure this is not enqueueing data again?)

-Check with event inspector window to see the sequenceod events to see the sequence of events occuring to get better idea.