i am wondering if there is a solution for starting a parallel process in a submethod library containing a firmware command (or actually any step requiring the instrument property.
In more detail, I have a main method “A.med” including a submethod library “B.smt” and within “B.smt” I want to start a parallel process in function “C” by using the HSL command
_intAsyncDHandle = Fork(“_PerformDAsync”);
The problem is, since I want to use a firmware command in _PerformDAsync, I need the instrument passed to this function.
Within function “C”, I have the instrument as an input parameter, but its scope is local. The private function _PerformDAsync requires the instrument, but how can I pass it from “C” to “_PerformDAsync” ?
The HSL help file only gives the hint “Any data has to be passed into a function that a new thread is to execute by global variables.” (topic: Parallelism Code Examples)
thanks for replying but that’s not my issue.
Yes, I can pass the instrument to the submethod (B), but within B I want to start the private submethod C as a parallel process using the HSL command Fork() and here I cannot pass the instrument as an input parameter.
This makes sense if you think about an instrument as a single thread executing serialized instructions. Parallel processes are effectively for non-instrument asynchronous processes (i.e. execute command on an integrated device whose driver doesn’t have a status function).
I’m trying to imagine a scenario where you’d want to fork an instrument process to achieve parallel execution on a single instrument, and am coming up with very few use cases - perhaps something like using the channels/iSwap when a 96 MPH is performing an in tip chromatography based purification?
Even if it were possible, thinking about the failure modes and recovery options for simultaneous execution of pipetting or instrument commands makes my head hurt.
Thanks @chips-a-hoai, this might work (did not test) but the background of why I wanted to have the parallel function in a submethod library is the three-layer-architecture recommended by Hamilton. Therefore, I actually don’t want function D to be located in the main method, but since it must definitively run as parallle process, I have no other choice, as it seems.
@WillTurman there are many use cases where you would like to have parallel processes running. Indeed not, when these processes control the same sub-device (pipetting channels and 96 MPH are tightly connected), but if you think about a heater shaker or centrifuge running while you want to preper the following dilution step or - as in my case - checking a sensor installed at our air exhaustion unit (only for safety reasons).
Left side would be the function in your smt where you could pass parameters to (hard coded here). You then put them on task locals (also the ones you need to grab the device reference in the parallel process). The you fork your actual parallel process which is shown on the right (whithin the same smt).
As has been mentioned, logic may have to be added to prevent parrallel access to the same device if it’s physically impossible.
Thanks @Julian for your help, I think this is the right way to go.
One issue still exists though. When I remove the instrument from the input parameter list, the ML_STAR functions (including sending a firmware command) is not available anymore and I get the syntax error for the respective line (see image)
But still I get an error during runtime for this line saying “bad argument (0x23 - 0x1 - 0x34)” I guess I am missing the link between setting a firmware command via method editor using Command and Parameter
and the way to do it in HSL code. Do you have an idea?
I see, in case you want to still use functions from the toolbox instead of pure hsl, I would do as in my example and just call your actuall function with the device as input parameter from the function that’s started in parallel. In my example that would be “_FunctionWithParameter(ML_STAR,…)”. In “_FunctionWithParameter” you’d then see all ML_STAR steps as usual.
So in your initial example:
_intAsyncDHandle = Fork(“_Helper_PerformDAsync”);
and in _Helper_PerformDAsync you would then fetch the device ref and call _PerformDAsync with the device as input.
I hope I understood it correctly, but if I define _Helper_PerformDAsync with input parameters (e.g. ML_STAR) and then call the function using
_intAsyncDHandle = Fork(“_Helper_PerformDAsync”);
I get a underspecified actual parameters (0x23 - 0x2 - 0xd) error
The fork function, however, cannot take more than one input parameter…
That’s not how I meant it, I try to explain better:
You need 3 functions, one without input parameters, the others with the input parameters. I’ll list them in calling order:
StartAsyncTask(ML_STAR):
This starts the helper as parallel task. The helper fetches the required paramters and calls the actual function (which can also be in a different smt, e.g. on layer 3).
_Helper_PerformDAsync():
Function that’s called from the helper and in which you can use the STAR steps:
This was perfectly explained and should actually work, but I still get a bad argument (0x23 - 0x1 - 0x34) error in the line where I want to call the ML_STAR function (no matter if it is a firmware command or a LoadCarrier (single step) function). Did you try calling an ML_STAR function on your computer?
I have tried it, yes. My method:
Cooresponding smt functions in order of calling:
Starter(ML_STAR) //device as input parameter
Helper() //no input parameter
ActualFunction(ML_STAR) //device as input parameter
If you are getting the “underspecified paramters” error, there is still a bug where you try to call a function without passing the correct amount of parameters.
