Scan type

[Ashwolaa]

Hi all,

After using the daq_scan recently for both 1D and 2D scans, I think the selection logic should be changed.

Currently, we pick the scan type first and then select the actuators. In my opinion, we should pick the actuators and this will define the dimensions of the scan.
I just made a pull request to introduce a new parameter type inspired from the listitem of pymodaq. Instead of just selecting by clicking, I added a checkbox. This makes it clear for the user which actuator is selected for the coming scan.
According to the number N of actuators selected, the program then automatically proposes the different ND scans sub_type.

As I already discussed, I believe it is better to separate the creation of the position array to its ordering.

What I mean, is that the following logic could be applied to start up a scan:

• Pick actuators: Which actuators will be used during the scan?

• For each actuator,

1. define the position array: How do we create it?
   Linear ==) start, step, end
   String ==) 0,1,2
   Parsed==) 0:0.1:1
   Loaded ==) csv file

2. Some pre-shuffling?
   Standard, Random, back and forth, sparsed, ...

• From the number of selected actuators, the program automatically detect the scan type. It can then offer sub_types option to decide how we shuffle the positions between the actuators. What we need to do is :

1. Pick navigation axis which actuator is moved first

So for a 2D scan, (actuator0, actuator1) or (actuator1, actuator0)

2. Add some extra shuffling to go through the ND array? (This could already be done with the pre-shuffling I think but an extra step might be worth in some situations)

[Ashwolaa]

If you agree with the logic presented above, I will make some work on it. We should just discuss more thoroughly on how we want to tackle it.

[rgeneaux]

I don't know if I like the idea of the list of available scan types to be changed when you click the actuators. It's quite easy to uncheck/check the wrong actuators when you change between them and I wouldn't like the scan options to be deleted or hidden everytime that happens. I think I like the current behavior, it just checks if the scan you ask for is compatible with your actuators and gives you a message if not.
I do like your checkbox thing though. Perhaps even better would be to display numbers inside the checkboxes rather than ticks? So that we directly see which is the axis order. Is that possible ?

[Ashwolaa]

I agree that automatic updates can be annoying sometimes so a pushbutton could indeed be added.

However for the rest of the scan options, I do not get it. Right now, the scan options are always deleted when you change an actuator in a 2D scan for example. All the start/stop/step are reset. The way to fix that for me is to associate for each actuator a particular position array maker which is linked to it such that if you check/uncheck you still go back to the initial definition.

Concerning the checkbox, I had a similar idea and I saw that there is the tristate option which could be used in that regard. However, it requires a bit of work as many interaction choices are available. It may also be a bit annoying to use when you have a large number of actuators. This is why I thought a tuple could be clearer.
(0,1,2)

[seb5g]

I am a bit of the same opinion as Romain, that is I like the checkbox things as it makes it clearer (see my review on your PR #213 )

I also agree with you concerning the fact that the settings are always deleted when you change the actuators, that's because of the factory pattern that creates a new scanner everytime you change it. This should be fixed. I think one could use a kind of cache memory to keep track of the last settings that have been modified by a user and load them every time a new scanner is instantiated by the factory.

Finally about the thing you are proposing about first define the positions then apply some shuffling. I think it is better to keep everything within a factory. For instance, what could be the point of randomising/back and forth... something that has been defined by the parsing scanner where you can easily specify orders, ramps... I would rather add some more scanners and allows the user to specify in the configuration file which scan/subtype and values he wants as default (which was the case in version 3 and is not working anymore at the moment)

[Ashwolaa]

I think that the current setup just does not give sufficient freedom for the user and makes the approach quite redundant as it will likely introduce repetition in the code. The factory pattern perfectly makes sense in the generation of the position array for 1 actuator but it just does not seem suited for the extension to multiple dimensions.
As an example, let's say I want a scan with one actuator that is linear, an other that follows a parsed string and a last which just takes random value between an interval?

With the full scan factory pattern:

• I have to create a new entry
• I have to define it such that first entry is associated to the linear array, second to the parsed string and the third to a random array
• I have also to define an ordering of the scan, which actuators go first: linear/parsed/random or random/linear/parsed.

The problem comes two-fold:

• each time I want to associate a different combination of scan sub type I need to redefine all the parameter tree? This is just repetitive and very hard to correct if we want to change a definition in the way the position array is generated. For example a change in the linear case would have to be applied over every scanner factories instead of changing just one function. This is exactly the thing we wanted to avoid with it! This could maybe be avoided with some utility functions/subclassing but you get my point.
• secondly for each combination of sub-type I have to define a new factory, this is again a good way to produce errors as it will mostly be a pure copy/paste from the previous factory but just changing the ordering.

##################################

With a factory associated to the generation of the position array for 1 actuator:

• Easy to setup, just call the factory associated to this particular position generation: linear, parsed, random, ...

With a factory associated to the ordering/shuffling of the arrays:

• Also easy to setup, according to the dimension of the scan, you call a particular shuffler. So for a 2D scan sampling with act0=[0,1,2] and act1=[4,5,6], you use the 2D factory with the ordering parameter (1,0) or (0,1) to decide which comes first and then decide on how you want to sample the scan
  In the case (0,1), you could imaging having the different scan subtypes:
• Normal [(0,4);(0,5);(0,6),(1,4);(1,5);(1,6),(2,4);(2,5);(2,6),]
• Snake [(0,4);(0,5);(0,6),(1,6);(1,5);(1,4),(2,4);(2,5);(2,6),]
• Snake 2 [(0,4);(0,5);(0,6),(1,6);(2,6);(2,5),(1,5);(1,4);(2,4),]
• Spiral [(0,4);(0,5);(0,6),(1,6);(2,6);(2,5),(2,4);(1,4);(1,5),]
  And the case (1,0), would just flip it

The shuffler/ordering factory works on how we go through the index in each position array while the generator factory defines how the arrays are generated.

[seb5g]

Ok I now understand a bit better what you want. But for this discussion we have to think about the balance between achieving generality in the scans and practicality and applications. I may be a bit biased but to me a multi-dimensional scan will be less likely to be done than a 1D scan which will be the 90% majority of scans. So what you say may be interesting for 2D scans and above but is it really necessary to go for such a big change for a few cases? Anyhow, you can always define very complex multiple scans with unrelated shuffling using the tabular can type.

I'd like for other users to express their view on this before going to such a big modification of the DAQ_Scan layout