allow showing scans with differnt motors

[sergey-yaroslavtsev]

It was request by ID26.
Scans of same counter but different motors need to be plotted at the same time.
Scans are exactly the same except of motor name.
Actually it was already working but there was annoying pop-up error - but plotting was working for two scans.

This PR explicitly tries to use the same positioner (not by name but by counter number) or the first one - otherwise fails as before.

[sergey-yaroslavtsev]

Screen.Recording.2026-06-26.000112.mp4

[sergey-yaroslavtsev]

To clarify:
Before it was failing on next line data = phynxFile[path] producing an error when selecting several plots. The plot was working! but selecting one more was killing previous one...

Screen.Recording.2026-06-26.000439.mp4

[vasole]

Honestly, I fail to see what you are trying to correct.

Are you aware of the feature allowing multiple plots of alternating "entries" when one of the entries did not feature the scanned motor? It requests a minimum amount of entries selected, because when having just 3 scans, for instance, it is not cumbersome to select those needed. If you replace the missing motor by another one based on the index of the first one, you are going to break more important things.

From my understanding, what you show there it just requires to be in AUTO ADD mode.

[vasole]

Before it was failing on next line data = phynxFile[path] producing an error when selecting several plots. The plot was working! but selecting one more was killing previous one...

The feature allowing an incompatible selection to be applied on multiple entries ignoring the conflicting ones requires the same type of entry at start and end. The fact of ending the selection with a compatible or incompatible entry changes the behavior. It is intended behavior implemented to allow multiple selections of x.1 and x.2 scans because the x.2 was not containing the same datasets and it was cumbersome to alternate the selection by hand above a minimum of scans. For instance, if you start the selection with 1.1 and you end with 5.1 it will allow a multiple selection of scans even if incompatible (by ignoring the incompatible ones) while if you end with 5.2 it will complain.

[sergey-yaroslavtsev]

I fail to see what you are trying to correct

Actually before the error i showed in 2nd video did not pop-up. But at some moment it starts to. The logic of error is clear.
The problem is "auto replace" mode (which is most widely used one) - selecting several plots - handle change of a motor name (when rest is the same).

Are you aware of the feature allowing multiple plots of alternating "entries" when one of the entries did not feature the scanned motor?

No i am not. Please let me know.

From my understanding, what you show there it just requires to be in AUTO ADD mode.

I partially agree. it was my first impression. But in this mode if smthg wrong is clicked user need to redo everything (to delete one is possible through legend but since it is not open by default - it is not clear and easy)

It is intended behavior implemented to allow multiple selections of x.1 and x.2 scans because the x.2 was not containing the same datasets and it was cumbersome to alternate the selection by hand above a minimum of scans.

Sorry if i misunderstood. But if i am looking on older version of PyMca. The behavior was strange - i mentioned it above. (see next comment with video)

For instance, if you start the selection with 1.1 and you end with 5.1 it will allow a multiple selection of scans even if incompatible (by ignoring the incompatible ones) while if you end with 5.2 it will complain.

If Signal is incompatible it will fails now as well. I do not see the problem.

[sergey-yaroslavtsev]

This is old (5.9.5) behavior.
Selectin 1 then 2 then 3 makes 2nd disappear. Selecting 1 then 3 then 2 shows all three. No complaining about incompatible axes. I think it is undesired behavior. But it was working for users for selecting simply two scans - and that is what they ask to bring back.

1 and 3 contains selected sampy while 2 is the same but having sampz instead.

Screen.Recording.2026-06-26.103924.mp4

[sergey-yaroslavtsev]

Just to clarify one thing:

...
            if (cnt == 'x') and (path not in phynxFile):
                scanned = NexusTools.getScannedPositioners(phynxFile, entry)
                try:
                    _logger.warning("Motor is missing, trying to use same number of scanned positioners")
                    selectedIndex = selection[cnt][0]
                    path = scanned[selectedIndex]
                except IndexError:
                    _logger.warning("Motor is missing, trying to use first scanned positioner")
                    path = scanned[0]

            # get the data
            data = phynxFile[path]
...

if path not in phynxFile is True then next line data = phynxFile[path] would fail trying to read the data.
Thus, this addon is kind of a last resort to try instead of failing the plot.

[vasole]

if path not in phynxFile is True then next line data = phynxFile[path] would fail trying to read the data.
Thus, this addon is kind of a last resort to try instead of failing the plot.

My point is that if you do that, the other functionality where one actually wanted to skip them will be lost. A functionality that BTW was requested by the spectroscopy beamlines (including ID26).

Usually one wants to compare apples with apples and oranges with oranges. Trying to co-plot two things on different motors is basically non-sense. Nobody warrants the ranges will be compatible. It is preferable to totally avoid to select an X axis in that case to compare signals. It is perfectly acceptable that if the user wants to do such a thing selects to explicitly ADD things to the plot.

AUTO REPLACE is the most used mode by ID26, not everywhere.

[sergey-yaroslavtsev]

Trying to co-plot two things on different motors is basically non-sense.

Then current behavior is a bug? And the old behavior (which was similar but with no error) was also a bug not a feature? Should it be fixed then? Please have a look the second video.