Data timestamping & Running two VIs concurrently

Post Reply
Jay
Posts: 3
Joined: Tue Nov 27, 2007 9:37 pm
Location: Troy, NY

Data timestamping & Running two VIs concurrently

Post by Jay » Tue Nov 27, 2007 10:23 pm

Hi,

I'm wondering if the Actiview-Light code (or full version for that matter) has an option for time-stamping the data? In other words, an additional row added to the data matrix and populated with a time-stamp. At 8192 Hz, I'm thinking it would need at least 0.0001 second resolution. Does that sound correct? If anyone has implemented this, inside or outside of Actiview, I'd greatly appreciate an idea of how you did it.

Also, being relatively new to Labview, I'm hung up on how to keep one VI running continuously (such as a DAQ vi) while calling and running sub-VIs. I found information on the "Preferred Execution System" (in VI properties) and tried running my first VI in a different Execution System than subsequent called VIs, but the calling via still halts upon launching sub-VIs. Then I came across an article on the NI Forum (id#=97906) (sorry, I'm not yet allowed to post links here) which says if a property node exists in the VI and is associated with a front panel object, that VI will ALWAYS operate in the UI Execution System (User Interface) Execution System. Due to the fact that all three of my VIs in the system have property nodes associated with their front panels, I'm inclined to think that all my VIs are running in the UI Execution System regardless of how I'm configuring them. So, it sounds like I would need to break-out the DAQ-specific portion of the code and move it to a separate, non-GUI oriented, VI in order to possibly successfully make the Execution Systems different. Has anyone had experience with this? Were you successful? I ask because extracting the DAQ code from the UI code looks to be a fairly large task... one I'm hesitant to begin working on without exploring all the options.

Thanks,
Jay

Coen
Site Admin
Posts: 925
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen » Wed Nov 28, 2007 7:37 pm

Because Windows is not a real-time operating system, it is not possible to accurately time stamp the data within ActiView. Proper time stamping can only be archived in hardware, for example by using the trigger port on the USB receiver.

LabVIEW allows multi-threading. You can run your additional VIs in a separate thread without interfering with the primary data acquisition thread. The separate threads are coded as parallel while-loops in the diagram. Examples can be found in ActiView. Four threads are running simultaneously: acquisition+display (large while-loop), low-battery popup, Jazz low-power popup, and open/close TCP/IP connection (3 small while loops at the bottom of the diagram). Communication between the separate threads is by global variables.

Best regards, Coen (BioSemi)

Jay
Posts: 3
Joined: Tue Nov 27, 2007 9:37 pm
Location: Troy, NY

New pursuit --> scaling (with Actiview-Light?)

Post by Jay » Wed Nov 28, 2007 11:04 pm

Thanks Coen. I had a feeling time-stamping was not going to be straight-forward / possible. Re. the Labview multi-threading aspect, I'll study the Actiview code and hopefully be able to make sense of the parallel while loops.

Another question came up today regarding scaling. I've read several forum posts that brush on the subject, but I'm still lost when it comes to scaling the Y-scale values that I'm recording. Sadly, we began our Actiview customization project (several months ago) using the "light" version which seemingly doesn't offer scaling. Is that correct or am I overlooking it in the light version? I do now see the Y-scale option in the full Actiview version, but for some reason I can't right-click the Labview front-panel objects on the full version and "Find" where their terminals are (to explore how it was implemented). What we're typically seeing come out of the Biosemi now is large negative values (ex: -107653048) and what we want to view and record is something in the -10 to +10 range. The units are fairly meaningless to us because we're feeding the waveform data into another algorithm that simply expects values in the range of +/- 10.

Thanks for your time, Coen.

Best, Jay

Coen
Site Admin
Posts: 925
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen » Thu Nov 29, 2007 6:24 pm

Right-click problem: the VI should be stopped (CTRL+.) and in Edit Mode (CTRL+M)

First, make sure that the ActiView VI is not running by pressing the red square on the About tabpage (or the "Edit" button in the Light version), or use CTRL+. (Control plus Dot). The toolbar should show up on top of the front-panel, and the arrow on the run button should be white. Then press CTRL+M to force LabVIEW into Edit Mode (or select from the pull down menu: Operate --> Change to Edit Mode). LabVIEW 8.x can show a non-running VI which is still in Run Mode (when you open a VI from a LabVIEW project), only after you press CTRL+M you can actually edit the VI (I was also initially confused by this feature when we changed from LabVIEW 7 to LabVIEW 8 ).


Scaling problem: the incoming I32 data values are the 24-bit values generated by the ADCs with an extra least significant byte added, and the data is not high-pass filtered in hardware (ActiveTwo is a DC system).

The ADCs in the front-end convert the analog input signals to 24-bit values with a LSB value of 1/32th uV (LSB = 31.25 nV), and an input range from +262 mV to -262 mV (2^24 * 31.25 nV = 524288 uV). The USB receiver converts the 24-bit values to 32-bit integers by adding a least significant byte of zero's to every data word. So, in order to convert the incoming I32 values in ActiView to microVolt, the numbers should be divided by 8192 (32*256). Please note that this is valid for the active electrode channels, whereas channels for passive electrodes and auxiliary sensors may have a different scaling, please inspect the BDF file header.
Since ActiveTwo is a DC system, the incoming data still contains the electrode offset values. These DC values are in the range of tens of milliVolt. The EEG data (0.1 - 100 Hz) is superimposed on these relatively large offset signals (also see http://www.biosemi.com/faq/24bitsystem.htm). Your example value of -107653048 represents -13141 uV, which is a perfectly normal value (an offset value of -13 mV is well within the recommended +/- 50 mV range) In order to convert the incoming signal into usual EEG data centered around the zero, high-pass filtering and/or base line correction routines should be used. For examples, please inspect the Ref-XXX.vi subVIs in ActiView.

Best regards, Coen (BioSemi)

Jay
Posts: 3
Joined: Tue Nov 27, 2007 9:37 pm
Location: Troy, NY

Post by Jay » Tue Dec 04, 2007 12:41 am

Thank you, Coen. You are on the mark about everything. I was ultimately able to implement the parallel While loop and get the DAQ running simultaneously with other VIs!

Thanks so much for your help!

Happy Holidays,
Jay

Coen
Site Admin
Posts: 925
Joined: Fri Mar 26, 2004 7:00 pm
Location: Amsterdam, Netherlands
Contact:

Post by Coen » Tue Dec 04, 2007 1:28 pm

Thanks for the feedback. Just one further remark: I forgot to extra emphasize to use global variables, and not local variables, to communicate between the parallel while loops. A pair of local variables is basically the same as a connection wire in the diagram. So, when write data to a local variable in one loop, and read this local variable in an other while loop, the second while loop will simply execute ounce after each iteration of the first loop. To achieve an independent running tread, it is essential that all communication to code outside the new while loop is done through global variables. Parallel while loops (or different VIs) can read and write a global variable, without influencing each others timing.

Best regards, Coen

Post Reply