Change IFCBacquire data directory when running beads

[rgov]

fluids:setsamplestorun:1              //Sets the number of samples to run
fluids:switchbeads:true                 //Sets the next sample to be a beads run or not
acquisition:start                                //Runs the next sample (normal, beads or ALT) with prime, debubble, flush

Wait for valuechanged:acquisition:stopped to determine that the IFCB is no longer busy.

Set fluids:switchbeads:false back.

[mbrosnahan]

Newest IFCBacquire version has ability to run built-in routines directly through interactive mode (as alternative to json scripts exported to Host/Routines). The update does not address problem specified here.
Running beads.json executes a beads run but writes the data to the standard output directory (typically /mnt/data/ifcbdata or /data/ifcbdata). It also does not write .hdr field 'sampleType' as 'Beads' but instead labels files 'Custom'. These two behaviors make it really challenging to sort beads data from time series samples. If beads are run according to schedule set by 'Beads interval' input in IFCBacquire UI, beads data ARE written to e.g., /mnt/data/ifcbdata/beads and .hdr field 'sampleType: Beads'
A secondary .hdr field that could be used to sort beads data is the 'runBeads' flag. This also is not updated by beads.json or executing the runBeads through McLane runBuiltIn interactive. From McLane, I think update so that we can change 'sampleType' is yet to be implemented but we should be able to toggle 'runBeads' flag and data folder using api commands.
It's important that these be set back after the beads run to their default/normal sample values* Otw sample data will be marked as runBeads: True and written to the beads output directory.

[rgov]

@mbrosnahan The solution @figuernd coded up is to change the data folder to append beads after the name.

This matches the behavior of IFCBacquire when fluids:switchbeads:true is toggled before running acquisition:start.

However the beads counter tracked by IFCBacquire will not be properly reset to 0. We could hack this into place but I don't think it's worth the complexity.

[mbrosnahan]

I agree that hacking of IFCBacq counters is not esp valuable.
we do want some indicator in hdr that a sample was from the bead reservoir or not. Can we set ‘runBeads’ parameter through current web api? If yes, we could sort beads from sample data through bead of hdr output files.
I’ve outlined another complication on slack that has to do with Tree option now available through the IFCBacq (associated with ‘FileHierarchy’ parameter in settings.txt and hdr outputs).

[rgov]

I don't know enough about the HDR files to understand, but I believe there is a field sampleType which says "Custom" for all of the routines that we submit, versus "Beads" for a "real" beads routine.

If we used the new IFCBacquire feature of adding an official routine as a step in a custom routine, I also do not know what the behavior is, whether it considers that a "real" beads run or a "custom" job.

I don't think the folder hierarchy option is that big of a deal, reviewing the IFCBacquire logic.

@figuernd We may need to revisit this if it is absolutely imperative that the HDR sampleType field be set to the right value. However I'm hesitant to send the command routine:beads because I've hit deadlocks in IFCBacquire doing non-interactive routines before.