{"action":"opened","issue":{"url":"https://api.github.com/repos/project8/dripline/issues/122","labels_url":"https://api.github.com/repos/project8/dripline/issues/122/labels{/name}","comments_url":"https://api.github.com/repos/project8/dripline/issues/122/comments","events_url":"https://api.github.com/repos/project8/dripline/issues/122/events","html_url":"https://github.com/project8/dripline/issues/122","id":102493360,"number":122,"title":"mantis interface request interval determination","user":{"login":"laroque","id":830135,"avatar_url":"https://avatars.githubusercontent.com/u/830135?v=3","gravatar_id":"","url":"https://api.github.com/users/laroque","html_url":"https://github.com/laroque","followers_url":"https://api.github.com/users/laroque/followers","following_url":"https://api.github.com/users/laroque/following{/other_user}","gists_url":"https://api.github.com/users/laroque/gists{/gist_id}","starred_url":"https://api.github.com/users/laroque/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/laroque/subscriptions","organizations_url":"https://api.github.com/users/laroque/orgs","repos_url":"https://api.github.com/users/laroque/repos","events_url":"https://api.github.com/users/laroque/events{/privacy}","received_events_url":"https://api.github.com/users/laroque/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/project8/dripline/labels/question","name":"question","color":"cc317c"}],"state":"open","locked":false,"assignee":{"login":"nsoblath","id":829991,"avatar_url":"https://avatars.githubusercontent.com/u/829991?v=3","gravatar_id":"","url":"https://api.github.com/users/nsoblath","html_url":"https://github.com/nsoblath","followers_url":"https://api.github.com/users/nsoblath/followers","following_url":"https://api.github.com/users/nsoblath/following{/other_user}","gists_url":"https://api.github.com/users/nsoblath/gists{/gist_id}","starred_url":"https://api.github.com/users/nsoblath/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nsoblath/subscriptions","organizations_url":"https://api.github.com/users/nsoblath/orgs","repos_url":"https://api.github.com/users/nsoblath/repos","events_url":"https://api.github.com/users/nsoblath/events{/privacy}","received_events_url":"https://api.github.com/users/nsoblath/received_events","type":"User","site_admin":false},"milestone":null,"comments":0,"created_at":"2015-08-22T01:20:16Z","updated_at":"2015-08-22T01:20:16Z","closed_at":null,"body":"I saw that in slack there was some discussion about what the \"right\" way to determine the interval for sending requests to mantis are. I'll summarize how it currently works and why, then welcome comments.\r\n\r\nFirst there is a base DAQProvider class which implements three important methods:\r\n* **start_run(run_name)** takes care of getting a run_id from the database interface\r\n* **start_timed_run(run_name, run_time)** schedules a call to end_run() after run_time seconds, then calls start_run()\r\n* **end_run()** resets internal parameters to the default/stopped state and cancels any scheduled end_run() timeouts (this allows you to use end_run on one started with start_run or start_timed_run without issue)\r\n\r\nNext, each there is a class which inherits from DAQProvider for each DAQ system. They override the parent start_run() and end_run() but are expected to use super() to still call the parent methods. This means each interface implements whatever actually needs to happen but the above behaviors are done the same across all DAQ systems.\r\n\r\nIn the case of the interface for mantis, the class also inherits from core.Spime (which allows it to behave like a sensor logger). The \"logging\" action for mantis is configured to be sending an OP_RUN to the mantis queue with appropriate parameters. This results in in an OP_RUN being sent every log_interval seconds. Aside from some unfortunate names (like log_interval) this is nice because it uses the same code and pika based asynchronous callback system to take care of timing those events (which means there aren't any blocking calls to things with long while loops or ugly threading blocks to deal with).\r\n\r\nOther considerations:\r\n* I want data taken with start_run() followed by end_run() some amount of time later, to be indistinguishable from data taken with start_timed_run(), assuming the right run_time is used, in terms of data quality. This means, for mantis, basing the log_interval on the total run_time is awkward.\r\n* One could consider initially sending two requests to mantis, that way there is always one sitting in the queue when an acquisition finishes and possibly deadtime is reduced. Starting a timed run could account for this extra time in a way that end_run wouldn't (the latter would tend to produce one more acquisition than a timed run), but at least the timing between acquisitions would still be consistent. *(Note to self: If we want to do this is should be as trivial as adding the line `self.on_get()` into MantisAcquisitionInterface.start_run after the call to super but before setting logging_status to 'on')*"}}