Tie lifetime of oni.Context to that of ContextTask

[jonnew]

• Instead of disposing and recreating oni.Context when a reset occurs, issue a oni.Context.Refresh() to existing object
• Fixes ContextTask.Reset() should call oni.Context.Refresh() instead of deleting and reopening context #407

Hardware Tests

I tried to put this throgh the ringer

Test	Desc	Result
Breakout only	Stated with breakout only, quickly hitting refresh during acqusition etc.	✔️
Breakout , NP2.0e	Added np2.0e headstage, which reliese on passthrough configuration, quickly hitting refresh during acquisition etc.	✔️
Breakout, NP2.0, Rhs2116 headstage	A Rhs2116 headstage, which uses a standard port but needs to issue a second reset after power up:	✔️
Breakout, NP2.0, Rhs2116 headstage with auto voltage	Same as last but do auto voltage discovery on rhs2116 headstage	✔️

[aacuevas]

Seems to be working with no apparent downside indeed.

[jonnew]

Looks like there might be an issue with Miniscope documented by @ChucklesOnGitHub

the red lines are indications of issues #406, #401, #408. So these changes might fix that, but the miniscope is now having issues. I will try to reproduce this.

[jonnew]

@ChucklesOnGitHub I am unable to reproduce this issue. This is the workflow im using:

Note that miniscope voltage autodiscovery is being used. No issues running this and capturing analog data from breakout and image data from miniscope.

Can you tell us exactly what error you're encountering? You can right click and copy the message at the bottom left of the bonsai editor when an exception occurs to get a detailed log.

[ChucklesOnGitHub]

For me, the issue was present using a workflow with only the breakout board:

Only in test 2 did the issue appear when using the miniscope, all other miniscope tests (4,6,8 in the table above) were fine.

[jonnew]

Hi @ChucklesOnGitHub, I need clarification about the word "issue".

From the table, I think "issue" refers to the large issue that this PR is attempting to solve. Namely, that in some cases, after stopping the bonsai workflow, the hardware remains engaged as if it was acquiring data instead of stopping normally. Lets call this issue 1. The second issue that I see, is that with this PR applied, there is another secondary issue that appears which is a "Failure to write stream or register" exception. This is a problem, but one that is actually in line with normal operation and some communication issue happening. Let's call this issue 2.

Is this assessment correct? If so, I am not able to reproduce issue 2. In order to figure out if its being created as a result of this PR, i need to know where its coming from. What is the Node in the workflow that produces the exception and if you can copy to the extended text of the exception that would be helpful.

[jonnew]

OK, so @ChucklesOnGitHub and I met out of context to clarify the situation. It turns out that there a couple of separate issues.

• First of all, Issue 2 in above definition appears to be read herring. Upon revisiting PR code, the miniscope is OK, or at least as OK as the auto-voltage discovery will allow given its inherent limitations

• Issue 1 is also solved with this PR

• A final issue (Hardware stays engaged for 30 seconds after workflow is stopped #401) is that even when stopping the workflow did shutdown the hardware, sometimes this took up to 30 seconds after the workflow was stopped to occur. This was a result of something that is a problem from the users perspective, but actually is not a logical error or but in the code. It occurs because @ChucklesOnGitHub downloaded this example workflow and removed the miniscope to test the breakout in isolation. In this case, the only device that was producing data was the heartbeat. Further, in that workflow, which must have been produced using a old version of the library, the heartbeat rate is set to to 10 Hz

  

  It should be hardcoded to 100 (Hardcode ConfigureHeartbeat to enabled in ConfigureBreakoutBoard #359). Combined with the large ReadSize that was originally required for the Miniscope, the read buffer took very long to fill in order to allow the read_frame() call to return and hardware shut down to proceed. I'm going to address this separately in Hardware stays engaged for 30 seconds after workflow is stopped #401.