|
| | __init__ (self, executable_pathname, library_pathname, log_level, log_queue) |
| |
| | connect (self) |
| | Spawn the sub-process which actually communicates with our KIAConsole.exe via stdin/out in a background thread (so that KIAConsole processing delays, which can be considerable, do not affect the ENLIGHTEN GUI response time).
|
| |
| | continuous_poll (self, args) |
| |
| | disconnect (self) |
| | Kill the subprocess by passing a "poison-pill" request downstream.
|
| |
| | get_response (self) |
| | Feature calls this to fetch the latest KIA response, if there is one.
|
| |
| | reset (self) |
| |
| | send_request (self, x_axis, spectrum, max_results, min_score, measurement_id=None) |
| | enlighten.Controller calls this to identify the last-collected spectrum.
|
| |
| | verify_connection (self) |
| | check to confirm subprocess spawns okay, by checking for exactly one "True" object on the response pipeline
|
| |
This class encapsulates ENLIGHTEN's interface to KnowItAll.
- Design Considerations
This needs to be in a background thread, so we can process newly acquired spectra when there is no pending match in-progress. Therefore, we're borrowing some architecture from WasatchDeviceWrapper.
The subprocess will communicate with KIAConsole via the text protocol used by KIAConsole. The subprocess will communicate with the MainProcess.KnowItAllWrapper via picklable Python objects.
Currently no attempt has been made to integrate this into the RamanMatching class as an alternate matching engine, though it certainly should be. Right now I'm just providing a quick "proof-of-concept" integration to show that the executable and linked library and signature database can indeed be accessed from within ENLIGHTEN in timely fashion.
- Multiprocessing Shenanigans
Note that multiprocessing.Process().start() explodes if the Wrapper contains callbacks to Controller. (Controller is a QThingy that can't be pickled.)
- Todo
support authentication (look for "expected" within match results)
support good/bad (look for known-good and known-bad results, returning binary indicator)
| enlighten.KnowItAll.Wrapper.Wrapper.connect |
( |
| self | ) |
|
Spawn the sub-process which actually communicates with our KIAConsole.exe via stdin/out in a background thread (so that KIAConsole processing delays, which can be considerable, do not affect the ENLIGHTEN GUI response time).
This is essentially a private method, as the initial connect is driven by the "enable" checkbox.
| enlighten.KnowItAll.Wrapper.Wrapper.send_request |
( |
| self, |
|
|
| x_axis, |
|
|
| spectrum, |
|
|
| max_results, |
|
|
| min_score, |
|
|
| measurement_id = None ) |
enlighten.Controller calls this to identify the last-collected spectrum.
x should be in wavenumbers, since KIAConsole is hard-coded to use KIA's Raman module. This function packages the request into a request object and then sends to the subprocess for matching.
Only one request can be active at once, so if a pending request is already in-process, this request is rejected outright (not queued, as ENLIGHTEN can collect data far faster than KIA can process it).
- Todo
- address use-case of identifying loaded spectra, perhaps via a process(x, y) method