LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

using an event structure in a state machine for shimmer accelerometers


1) Press Connect

2) Value change of Connect is registered by event structure in Idle state

3) Triggers change to connect state

4) BT accelerometers connect then automatically goes to configure state

5) configures accelerometers and then waits here until user action goes back to Idle state


This is what you want. Yeah it's just fine to go from the connect state to the configure state, but you always want to go back to the Idle state. There is only one event structure and it's in the idle state. Multiple event structures can lock up a program pretty quick.

Now, based on what the user has already pressed, or states that the program has gone through, you can disable user interface functionality to keep the same state from being triggered again. This is how you would handle the requirement that the user can't "connect" twice.

Example:

  1. Goes to Connect state
  2. Property node in Connect state disables the Connect button and enables the Disconnect button
  3. Goes to Configure state
  4. Goes to Idle
  5. User clicks Disconnect, goes to Disconnect state
  6. Property node in Disconnect state enables the Connect button and disables the Disconnect button

This is how a top level application would work in terms of the user interface and is how I do it normally.

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 11 of 21
(1,336 Views)

atrinh wrote:

The connection/configuration event takes 5-10 seconds and then it sits their waiting until another user event. This parallels the original VI.


That's too long for an event based single-loop state machine. You need to seperate out the UI code from the consumer code. It is not good to have the event structure unavailable to react to events for 5-10seconds because of dataflow constraints. If there is an impatient user, he might queue up dozens of events or lock up the Front panel, depending on how things are configured.

 

 

0 Kudos
Message 12 of 21
(1,319 Views)

That makes a lot more sense!

 

Now the one I would have a lot of trouble with is where to put "Capture" which is when the program would live stream data. My first thought was to create a capture state where it would just poll the acceleroemters and collect. But because the user would like to stop the streaming at some point, I am thinking this code should be placed in the idle state...... What would you recommend for handling this?

 

Anton

0 Kudos
Message 13 of 21
(1,316 Views)

@atrinh wrote:

Now the one I would have a lot of trouble with is where to put "Capture" which is when the program would live stream data. My first thought was to create a capture state where it would just poll the acceleroemters and collect. But because the user would like to stop the streaming at some point, I am thinking this code should be placed in the idle state...... What would you recommend for handling this?


It's starting to look like you might want to implement a parallel loop for the streaming. That loop could have a case structure within it so that it's not capturing when you dont' want it to.

 

Altenbach, I think in this case the user would be okay with waiting because they need to configure before they do anything else. Atrinh could use Set Busy.vi and Unset Busy.vi to disable the mouse in the main window during this configuration period to avoid multiple user inputs lining up. 

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 14 of 21
(1,309 Views)

Sorry I am not sure how this parallel loop would look like. Would this be a case structure within a while loop, all contained within the main while loop? Or is this outside of the main loop? If the latter, how can I pass the accelerometer settings from the main loop to the other loop without exiting the main loop?

 

Anton

0 Kudos
Message 15 of 21
(1,284 Views)

You could have the Timeout state handle the streaming, but then you'll have weird gaps in your data if the user does anything during streaming. Are you using DAQmx by any chance to acquire data, or do you have to loop every single time to get a new data point? If you have DAQmx, then you could get away with the Timeout case because the DAQmx task keeps up with the data rate.

 

Here's a quick example of how you could lay out a parallel streaming loop if you need the loop to keep a constant rate. It gets a little complicated if you add on to this code, so you have have to be careful. There are many different ways to do a parallel streaming loop, but I don't have time to go through them all, this is just a simple, easy one to understand.

ExampleStateMachine with ParallelStream.png

Cheers


--------,       Unofficial Forum Rules and Guidelines                                           ,--------

          '---   >The shortest distance between two nodes is a straight wire>   ---'


0 Kudos
Message 16 of 21
(1,279 Views)

Hi James,

 

I have been working on the program for about a week no and still no success. The Action string command gets passed through the shift register but once it enters the Shimmer Subvi, for some reason it calls for disconnection.

 

I've gone as far as designing the state machine so that there is just init, idle (or in this case "live"), and save states. This machine would connect, configure, stream, etc all within the idle state and then transition to save and write the data from the qeue. This way would remove the need to have a separate external save loop as they have designed it. This was an attempt to save the streamed data in separate files for each time the user presses start for a new trial. Still no success here.

 

I am contemplating just leaving the stock subvi as it is and just adding a way to collect audio each time the accelerometers are streaming. I've done this by adding another separate while loop but is there a way to synchronize the audio collection with accelerometer streaming?

 

Basically what I am trying to accomplish is to have a program that can collect blue tooth accelerometer data and audio simultaneously. I have been trying to design the program so it would stream and save individual files for each trial completed (e.g. walking while counting, walking while listing onjects in a category, etc.).

 

Currently, the accelerometer file that is written by the stock program contains breaks in it so a user like me could break the data into separate trials. Great. But... I can't break the audio file into separate files to match with the accelerometer data which is the ultimate goal. How can I collect separate audio files in a single run of the program?

 

Thanks for all the help so far. Any help or even advice would be great.

 

Anton

0 Kudos
Message 17 of 21
(1,228 Views)

Hi Anton,

 

What driver are you using for the accelerometer and where did you obtain it?

 

Thanks,

Regards,
0 Kudos
Message 18 of 21
(1,186 Views)

Hi AC,

 

The drivers would be from the shimmer accelerometers. First time you use them, you add them through the device manager in windows.

 

Anton

0 Kudos
Message 19 of 21
(1,135 Views)

Hi Anton,

 

I haven't been able to find any Shimmer Accelerometer drivers which are offically supported by National Instruments.  Because the drivers you are using come with your accelerometers, you may have more luck in the context of your most recent question contacting Shimmer.  This forum will be helpful for questions about LabVIEW and NI products, but for specific questions about the behavior of the Shimmer VI, it will probably be most helpful to you to contact Shimmer.  That being said, if you could verify the name of the executable for the driver, I can try to track it down to investigate the disconnection problem you are seeing. 

Regards,
0 Kudos
Message 20 of 21
(1,101 Views)