search

rpeltekov / ge3t_shim_tool

Conformal Shimming for GE3T using ExSI and OpenSourceImaging Shim Drivers
MIT License
1 stars 1 forks source link

make exsi_client.py self sufficient #3

Closed rpeltekov closed 3 months ago

rpeltekov commented 3 months ago

the exsi_client has some dependence on the gui right now with respect to the threading variables that are used within it. it hangs whenever you try to run it on its own without the gui / shimTool driving it.

make sure that those are not necessary and that you can create an exsi_client instance and drive the scanner completely on your own from the python CLI

also add documentation to further explain how the exsi_client works so that others can easily grab it and use it.

rpeltekov commented 3 months ago

some explanations that I added that might be useful later to recompile into documentation:

Robert Peltekov 10:21 AM so i just finished the task i was on from the other day and looked into the exsi program running independently with a clearer mind 10:21 lol 10:21 it was a super simple facet of the program that was making it look like it was "hanging".

Robert Peltekov 10:31 AM there are three threads: main thread and two child threads being the receive loop and command loop. command loop takes commands executed and queues by the main thread and sends them to the scanner whenever the scanner can ingest them. This timing is dictated by the receive loop which processes each message from the scanner whenever the scanner replies and uses that info to trigger threading variables that the command thread (and the main thread in only on startup) need to wait on. The reason that the it looked like it would not do anything after load protocol, was because i forgot to realize that we should be waiting on these thread condition variables. the first being the ready_event when the scanner is actually connected, and the second being whenever "images are ready" or essentially when a scan is complete. What i saw happening was that the main thread simply queued all the commands, and then since it has nothing else to do it dies. then because the child threads are daemon threads (because i didn't want to deal with leaking resources and whatnot during dev) they also die and nothing ends up getting sent to the scanner to initiate the scan after the load protocol happens... anyway this is simply fixed by just adding the line for waiting, but i will see if i can make it more interactive, and maybe just have the client spin up a seperate process to always run while the main program is running so that you can have it exist within your jupyter notebook.

Robert Peltekov 11:57 AM if you want to use this exsi stuff, it works in the independent script method, not python notebook yet. please pull the latest code, and refer to here: https://github.com/rpeltekov/ge3t_shim_tool/blob/main/examples/test_exsi.py#L38-L40 for how to get the list of tasks that got loaded, so then you can queue them out of order. i think #L33 and #L50 were the lines of code that were missing that we needed to make sure that the script at least waits for the connection to be good before starting to queue, and to not die before the first scan is done.