Unfortunately, even with the unique identifiers, only one Measurement channel can have the units updated. For example, if I change M1 to Hz, it will work if I'm not on the Current Value screen. Switch to CV, and it shows Hz. Then I try to change another M channel, and the value changes appropriately, but the unit doesn't update, despite the allModes variable updating correctly. For example:
getallModes?
;; noU1,V2,V3,Hz4,V5
That will show no unit on M1 (as expected), but M2 through M5 still show V as the unit, despite M4 clearly being set to Hz. Whichever mode I change first will update once, but any change after that is ignored, even on the same M# channel.
Doing a mode/column change is a fairly complicated procedure in TC, this makes it hard for me to inspect the code and guess on what goes wrong.
One detail: Please do not use invalid column names like noU1, instead leave it out. Columns with a column name that is not present in the mode list will not be shown.
One option is I make a special TC with some extra logging build in and you test with that?
I'd be happy to try a extra logging build to sort this out. I think there is a bug hiding when using complex unit changes.
noU1 is a valid selector following the format:
;#value name unit format {selector}
noU1 works fine when selected. TC requires each M# to have a unique {selector}, otherwise each M# with a matching {selector} will have that {selector} line visible on each channel, whether intended or not (for example, 5 channels, 5 data sets, activating a 2nd mode will show 2 modes for each channel with matching selectors; creating 10 channels, and still only receiving 5 data sets if the selectors are not unique).
Each of the items in this works as expected:
;; noU1,V2,V3,Hz4,V5
noU1 is no units (uses _ for Unit column) on M1, V2 is Voltage on M2, V3 is Voltage on M3, Hz4 is Hertz on M4, and V5 is Voltage on M5.
This is the first 2 M# channels:
;#value name unit format {selector}
#value M1_Volts V SI V1
#value M1_Amps A SI A1
#value M1_Vs V SI Vs1
#value M1_Seconds s SI s1
#value M1_Hertz Hz SI Hz1
#value M1_Percent Percent SI Percent1
#value M1_ _ SI noU1
#value M2_Volts V SI V2
#value M2_Amps A SI A2
#value M2_Vs V SI Vs2
#value M2_Seconds s SI s2
#value M2_Hertz Hz SI Hz2
#value M2_Percent Percent SI Percent2
#value M2_ _ SI noU2I can set any unit {selector} variable, and it will work correctly when I use the cmdMode button:
#scpiCmd getallModes? none?
:readmath: allModes
#askMode getallModes?
#askValues DynamicM1?;DynamicM2?;DynamicM3?;DynamicM4?;DynamicM5?
#modeFromVar allModes
#readingDelay 1
#modeChangeDelay 1
#cmdModeLayout 1 5
#cmdMode Update_Modes getallModes?
getallModes?As long as I'm
not on the Current Values tab, I can set the modes however I want ONE time using cmdSetup:

Then I can switch the values in cmdSetup, and it correctly sets the variables, and updates the scope data acquisition correctly, but the displayed mode units do not update as expected:

Instead, I must go to the Modes button and (when not on the Current Values screen) I can click the button to update the modes, and it works correctly:

So this seems to be an issue with the way TC updates the modes/units. The issue with #modeFromVar seems similar to how it was before, so the bug might be deeper. I don't know. I'm happy to run a more detailed logging version to try and find out.
Alternatively, if you specify a device that you have with simple SCPI, I can make a modified version of that device's file with similar mode switching (actual data from the device is irrelevant, we just need modes to switch) that you could test as well.
Thanks,
Josh
ETA: I did further testing, and it doesn't matter how many channels or mode selectors are used. I reduced it to 1 channel with 2 mode selector options, and the behavior described above persisted. Updating based on a Variable appears to be the issue.