Track trigger timing

[Evelina Tapia]

Hi,

I am creating an experiment where a TMS is triggered at various points
during a trial sequence (where several stimuli are presented). I have
InLine code at the very beginning of the experiment that randomizes
the onset of the trigger. What I want to be able to do is to timestamp
the execution of the trigger -- in other words, I want a timestamp
when the line of code in InLine for trigger TMS is begun/completed and
I want to log that data together with other information in the
final .edat file. For that purpose I have declared 2 global variables
"PulseOn" and "PulseOff" under the User tab in the Script window. In
my InLine code right after trigger is executed (and I know that the
trigger works just as it should) I have added

PulseOn = Clock.Read
c.SetAttrib "PulseOnset", PulseOn

and similar code is placed after the port is turned off for trigger
offset time stamp. However, when I run this code, the variables
PulseOnset/Offset are not saved in the data file. I have also tried to
use c.Log in this InLine but then only one line of data (one trial) is
saved and although trigger onset/offset are marked, there is no more
any data about the objects presented during the trial.

In the documentation I have found that "a variable must be set as an
attribute of the context object in order to be logged in the data
file" so I assume that the issue here is that PulseOn/Off aren't
really "attached" to any object in the experiment... Is there a way
around that? Or another way to log the onset/offset of the trigger?

THANK YOU!

Evelina

[Michiel Spape]

Hiya,
What you're saying doesn't sound like anything E-Prime should omit. The only reason I can see your data is not being saved is that for some reason, these lines are skipped. There can be many reasons for this (say, a button-press causes a goto to fire), but what you would need to find out is whether you are actually logging anything. That is, just move the inline thingy forward/backwards along the procedure and see whether anything is logged. I'd also recommend shortening the line to
c.SetAttrib "PulseOnset", clock.read
so that you don't even have to declare any variable.

One question though: is _nothing_ being saved, or is PulseOnset found somewhere in your edat file, but with nothing in there? If the former, then the line is presumably skipped (as i had assumed based on what you write). If the latter, then a number of other things may be going on (e.g. it's saved under a sub-trial level thus easily overlooked).

One final thought: I'd first get everything running, THEN start thinking about adding TMS triggers and whatnot. It's far easier to add advanced bits to the working basics than vice versa. Can you, for instance, get a Stroop experiment (or any of the tutorial experiments) running with a c.SetAttrib "MyExtraLoggedData", clock.read added?
cheers,
Mich

________________________________________
From: e-p...@googlegroups.com [e-p...@googlegroups.com] On Behalf Of Evelina Tapia [eve...@illinois.edu]
Sent: 04 January 2011 18:13
To: E-Prime
Subject: Track trigger timing

Hi,

THANK YOU!

Evelina

--
You received this message because you are subscribed to the Google Groups "E-Prime" group.
To post to this group, send email to e-p...@googlegroups.com.
To unsubscribe from this group, send email to e-prime+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/e-prime?hl=en.This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

[David McFarlane]

Evelina,

Mich pretty much covered it. I will add only the following:

For debugging purposes, you can sprinkle the code with MsgBox or
Debug.Print statements so that you can trace execution flow and see
if the code really goes where you think it does. MsgBox will mess up
the program timing, but will show at run time where your code is, and
will work outside of E-Studio; Debug.Print requires running from
E-Studio, but offers some other niceties.

I would not use a c.Log anywhere except in exceptional circumstances
(e.g., a loop within a Procedure where I want to add extra log
lines). The Procedure already supplies a c.Log where needed, each
extra c.Log that you add also adds another line to the log, which is
rarely what you want. More to the point, simply using c.SetAttrib
already does everything needed to added an attribute to the log,
since EP automatically addes the required c.Log (don't take my word
for that, look at the generated code just before End Sub of your Procedure).

The PulseOn/Off need not be "attached" to any object in the program
(and as Mich pointed out, you don't really need the variables at
all). As described it looks like you are doing everything correctly,
so we must be missing something. Which brings us back to the general
debugging tips offered by Mich & me to see if the program flow really
goes where you think it does.

Good luck,
-- David McFarlane, Professional Faultfinder

[Evelina Tapia]

Michiel and David,

Thank you very much for your suggestions. My program worked as it
should without the TMS trigger. I have finally figured out the
solution to this problem and will post it here in case someone else
has a similar issue.

Originally, the InLine script that sent the trigger to the TMS was
placed at the very beginning of the experiment. That is where I also
coded my variables (right after trigger code I had [PulseOn =
Clock.Read]). So, it turns out, probably not surprisingly, that this
InLine is read only once during the experiment (although if anyone
could explain how the trial procedure knows when to execute the
triggers which are specified and read only once at the beginning of
the expt, I would appreciate it :)) and, therefore, all PulseOnsets/
Offsets will have the same value on a trial-by-trial basis. In order
to update PulseOn/Off variable I had to move the InLine with triggers
to the beginning of the trial procedure (which I didn’t do originally
due to some other issues with the trigger). I also created empty
columns (called PulseOnset/Offset) in the trial List because that is
where the variables will be stored. The code is printed below.

Happy programming!

Evelina

************************************************
‘Here PulseSOAs is a List with trial parameters
'For zero SOA trigger on Target
If PulseSOAs.GetAttrib(1, "SOAcondition") = 0 Then
Target.OnsetSignalEnabled = True
Target.OnsetSignalPort = &H378
Target.OnsetSignalData = 128

'Timestamp pulse onset
‘PulseOnset is a blank column in PulseSOAs List
c.SetAttrib "PulseOnset", Clock.Read

'Resets port
Target.OffsetSignalEnabled = True
Target.OffsetSignalPort = &H378
Target.OffsetSignalData = 0

'Timestamp pulse offset
‘PulseOffset is a blank column in
PulseSOAs List
c.SetAttrib "PulseOffset", Clock.Read


'For positive SOAs trigger on Blank
ElseIf PulseSOAs.GetAttrib(1, "SOAcondition") > 10 Then
Blank3.OnsetSignalEnabled = True
Blank3.OnsetSignalPort = &H378
Blank3.OnsetSignalData = 128

'Timestamp pulse onset
c.SetAttrib "PulseOnset", Clock.Read

'Resets port
Blank3.OffsetSignalEnabled = True
Blank3.OffsetSignalPort = &H378
Blank3.OffsetSignalData = 0

'Timestamp pulse offset
c.SetAttrib "PulseOffset", Clock.Read

End If

[Peter Quain]

you don't need any blank columns in a List (PulseOnset/Offset), no
values are writen there at runtime. SetAttrib sets the value of an
attribute, and stores that value in the LogFile in a column for that
attribute, not in any List.

[Evelina Tapia]

Peter is most likely correct about not really needing the empty
columns in the list. I just went by some examples off of E-Prime's
website and didn't test the code without those empty columns.

Also, I should add that the timestamp in the code I posted earlier
will be for the moment E-prime reads/executes a specific line of code
but the timestamp itself will NOT reflect when the trigger was sent.
The trigger is always sent at the osnet of an object on which the
signaling is enabled so the TimeOnset of that object is the timestamp
of when the trigger was executed. It took me sometime to figure that
out =]

Evelina

> >http://groups.google.com/group/e-prime?hl=en.- Hide quoted text -
>
> - Show quoted text -

[David McFarlane]

Evelina Tapia wrote:
>Peter is most likely correct about not really needing the empty
>columns in the list. I just went by some examples off of E-Prime's
>website and didn't test the code without those empty columns.

This might be a moment to remind folks that generally the examples
provided by PST are rather sloppy and cannot be taken as models of
proper programming practice. Take the PST examples merely as hints
and exercises and then use your own judgment.