Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intertrial start display returning too early #86

Open
floesche opened this issue Jun 29, 2023 · 12 comments
Open

Intertrial start display returning too early #86

floesche opened this issue Jun 29, 2023 · 12 comments
Assignees

Comments

@floesche
Copy link
Collaborator

floesche commented Jun 29, 2023

Via slack:

I'm seeing this on the host - pattern 7 is an intertrial, it's showing the intertrial parameters are received, the start display is received, and .03 seconds later the parameters for the next condition are received, like the code is continuing to run even though the start display with a duration of 1 second has just been received.

I checked that the duration is right. Here's a picture of the stream on the host. I was thinking of setting the waitforend manually just in case but if it's true by default it shouldn't make a difference.

screenshot_2023-06-28_at_5.16.58_pm_11038_.png

This is for G4_run_protocol_blockLogging.m. The conditions are spaced appriopriately in the host's feed and there's no difference in their startDisplay command and the intertrial's, but for some reason the host stream for every intertrial looks the same - no time between the start display being received and the next commands being received.

Thing is it works fine with the code on the master branch, so I would think it has to be something to do with the run protocol, but I don't know. HM was having the exact same problem, but only a couple flies in. Today she ran ten flies and didn't have the problem at all. But with the new protocols it happens every time. I thought if commands are being sent to the host while the intertrial's start display is still going, maybe it was getting backed up after several flies, but with the new code it happens from the beginning so I'm just not sure.

it just looked from the timestamps in the host stream like the waitForEnd thing was not working with the intertrial's startDisplay command, that was the only thing I could think of that would cause it. But i have no idea how that would happen, so it could be something else.

@floesche
Copy link
Collaborator Author

The display is in the wrong mode. On the TCP level it reports: "Start-Display command is invalid during Stream Pattern Position mode"

@floesche
Copy link
Collaborator Author

Via slack

Is that new, start-display not working with mode 3? With the master branch code it works fine. If that’s the issue it’s an easy fix.

@floesche
Copy link
Collaborator Author

That behavior of G4 Host (with start-display) is not new, but maybe in the master branch the G4 Host is set to a different mode?

@floesche
Copy link
Collaborator Author

Via slack

The experiment protocol sets the mode. The intertrial is mode 3 no matter what version of the code you use

@floesche
Copy link
Collaborator Author

I changed the mode in the Designer to 1 and the protocol ran for me.

@floesche
Copy link
Collaborator Author

Via slack

Now that I know what to look for I’ll look into it too. I can simply update it to only give a start-display command in modes other than 3. I’d have to ask S. if mode 1 would work

@floesche
Copy link
Collaborator Author

We can think about how to report this type of error in the future. With PanelsController we now have access to this type of feedback, if we want to

@taylorlm88
Copy link
Collaborator

One question, how are you supposed to set the duration of the trial if you cannot submit the start-display command in mode 3?

@floesche
Copy link
Collaborator Author

It might actually not be an issue of mode 3 (since that wouldn't make sense in my point of view) but that another parameter is missing. Maybe G4 Host error reporting is not very good. We need more tests to figure this out.

Once we know, we can check and circumvent this with some more checks inside PanelsController.

@floesche
Copy link
Collaborator Author

Mode 0 and mode 3 don't support Start-display at least since v240 of the G4 Host (probably earlier, too, but that's how far I checked).

image

I am not sure what the display actually shows in the master branch, but it can't be correct. In the master the run protocol will just wait a certain amount of time for each intertrial.

In the NewestVersion branch the intertrial will only wait if the pattern on the display is what was specified and will otherwise just continue.

@taylorlm88
Copy link
Collaborator

I closed this on Nov 6 but I'm not sure why as I can't find any indication we actually solved the problem, only worked around it.

If mode 3 does not use the start-display command, perhaps if you set the mode to 3 and set the pattern, it will just come on the screen? I need to experiment and see if I can figure out how mode 3 starts displaying on the screen without the start-display command. If I can't figure it out, we may need to ask Andy how you're supposed to trigger a condition in mode 3 to begin.

@mbreiser
Copy link

updated discussed today -- need to review use of mode 3 and decide if this is important enough to fix, and then by whom.

@taylorlm88 taylorlm88 self-assigned this Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants