False error message "Log failed to stop"
floesche opened this issue · 21 comments
After a 20min protocol run in G4 Experiment Conductor, an error message with "Log failed to stop" popped up, although the log in the Main host had stopped.
Do you remember which run protocol was being used? It looks like after the updates, this error dialog isn't produced anymore by the run protocols, so is it still an issue?
It just happened on d1b90da with the "Simple" run protocol.
This was the error in the MATLAB command window:
Error using waitforbuttonpress
waitforbuttonpress exit because target figure has been deleted
Error in PanelsController/stopLog (line 408)
waitforbuttonpress;
Error in G4_default_run_protocol (line 332)
ctlr.stopLog('timeout', 60.0, 'showTimeoutDialog', true);
Error in G4_conductor_controller/run (line 632)
eval(run_command);
Error in G4_conductor_view/run_exp (line 603)
self.con.run();
Error in G4_conductor_view>@(varargin)self.run_exp(varargin{:}) (line 140)
'units', 'pixels', 'Position', [15, self.fig_size(4)- 305, 115, 85],'Callback', @self.run_exp);
Error while evaluating DestroyedObject Callback.I also encountered the same problem this week after the updates to the code on the LED flight arena computer. I got the same error message as Frank, above. If I manually stopped the Log and waited it would eventually show me the pop up that is normally shown at the end of the experiment. However, when I tried to process the data from these experiments I got an error which I think is linked to the problem in stopping the Log.
The run protocol was ‘Simple’ for these experiments.
Just an observation / note to self: "Stop Display" and "Stop Log" are very close together. We should test if that is an issue and one command potentially masks the other.
Additional comment to those above.
I also see an error message in the command window but it's different to that seen by @floesche :
Error in G4_conductor_view/update_run_gui (line 447)
self.experimenter_box.Value = find(strcmp(self.con.model.metadata_options.experimenter,self.con.model.experimenter));
Error in G4_designer_controller/saveas (line 1235)
self.run_con.view.update_run_gui();
Error in G4_designer_controller>@(varargin)self.saveas(varargin{:}) (line 373)
uimenu(menu, 'Text', 'Save as', 'Callback', @self.saveas);
Error while evaluating Menu Callback.
This also appears to be linked to the length of time / the size of the protocol being run. The one that I am current running is 22 minutes long and has 32 trials. I tested one earlier that was only 3 minutes with 15 protocols and I didn't get the issue of the Log not stopping correctly.
It just happened on d1b90da with the "Simple" run protocol.
This was the error in the MATLAB command window:
Error using waitforbuttonpress waitforbuttonpress exit because target figure has been deleted Error in PanelsController/stopLog (line 408) waitforbuttonpress; Error in G4_default_run_protocol (line 332) ctlr.stopLog('timeout', 60.0, 'showTimeoutDialog', true); Error in G4_conductor_controller/run (line 632) eval(run_command); Error in G4_conductor_view/run_exp (line 603) self.con.run(); Error in G4_conductor_view>@(varargin)self.run_exp(varargin{:}) (line 140) 'units', 'pixels', 'Position', [15, self.fig_size(4)- 305, 115, 85],'Callback', @self.run_exp); Error while evaluating DestroyedObject Callback.
In the panelsController code, there are two different timeout message options. There's 'showTimeoutMessage' and 'showTimeoutDialog'. It varies by run protocol which of these is turned on. If 'showTimeoutMessage' is turned on, the dialog box pops up asking you to stop the log manually, but it does not tell you to hit a key afterward and there is no 'waitforbuttonpress' command, so the code is not waiting for the user to do something. If 'showTimeoutDialog' is turned on, there is a waitforbuttonpress, which is what triggered the error here. Is there a reason we need both of these? they seem to serve the same purpose. The error seems to indicate that the window was closed without a button ever being pressed, so waitforbuttonpress errored out. Which of these would we rather turn on in the case of the host response being empty?
Another question - what version of the host are you all using when getting these errors? I just ran two protocols on Eyal's old computer, host version 253. One was 22 minutes long and one was 30 minutes long, but I did not have an issue with the log stopping with either one.
It seems like the stop log has slowed down significantly with the recent release of v253:
@taylorlm88 wrote some code that demonstrates the problem. timeLogCommand.m1 starts the display 100 times for a randomized time of up to 10 seconds and then measures how long the stopLog command takes for each of those cases.
For version 247, there is a bit of a spread, but not much more than .4 seconds for a 10 second display command.
In version 253, it takes roughly twice the time to run the stopLog.
If this trend continues for longer logging intervals, closing down the experiment will take many more minutes than before. This might be related to what was observed above and caused the issue with our other scripts.
I seem to remember that we had a similar issue before, but can't point my finger to any issue right now (maybe this was in a conversation via email). Maybe this issue got re-introduced in the latest Host?
Is there another way to speed up the closing of the TDMS files and finishing the experiment after issuing a stopLog command?
Footnotes
@floesche Have we sent this to Andy? We can't really close the TDMS files and process them until the stopLog has actually finished running, because the Log command is actively writing to them, so we get errors if we try to handle them while stopLog is still going.
No, I think Michael wanted to do this. I'll ask him
@floesche build with close file logging delay fixed
Wow, that looks very good.
@taylorlm88 , would you want to test this first? Or should we install it on the other machines, too (@mbreiser, @SannaKoskela, @leburnett)?
The files are also at https://github.com/floesche/LED-Display_G4_Display-Tools/releases/tag/host-v254
@floesche I won’t be able to test it until tomorrow evening at the earliest, so up to you guys if you want to wait for me to test it out or if you want to go ahead and install. I’ll need to install it on the flight arena to test it out anyway.
Please test it whenever you have time.
@floesche I'm trying to see if I can optimize it a little bit more, but you can go ahead and test the latest version for now if you want.
If your measurements reflect the bigger picture (also for longer experiments that run many minutes), then this is all we need. Don't worry about optimizing it more for now.
@floesche I was already in the middle of optimizing so I just ended up finishing it. Here is latest build.
Thanks, the release is also at https://github.com/floesche/LED-Display_G4_Display-Tools/releases/tag/host-v255
I tested one of the protocols that consistently caused this problem using v255 and the stop log command no longer times out so I think this has fixed the issue! I didn't have time tonight but next will time the stop log command after a long protocol to see how long it actually takes, but from the protocol I ran tonight it seemed to be very fast.
@floesche Timing the stop log command after a 30 minute experiment, it took 4 seconds to run, so massive improvement! I don't think we'll ever run a protocol long enough to cause this issue again, so I'd go ahead and update all the computers to v255 if we haven't yet. Going to go ahead and close this issue.