buha / gpibcs Goto Github PK

waitsrq should wait until the STB & 0x40 condition is true
This works well on Linux and on Windows with 14.0 NI-VISA and NI 488.2 but does not work on Windows with 15.5 NI software.

This would avoid doing an ibrsp manually after each waitsrq

There is no Would you like to save/discard? style confirmation when switching to another sequence file.
Feedback from jlj implies that this is a common problem while using gpibcs and has led to some sequences being lost.

This does not occur on Linux or on Windows with version 14.0 of NI toolset
False posives are status bytes like 0x6 who don't have the bit 0x40 set.

The first action when loading gpibcs is to load the sequences. Help users 👷‍♂️ get straight to the action, no distractions

Debatable, but would reduce GUI clutter when working with long file paths.
Perhaps use the hint text as holder for the entire path.

Clicking Run does not change focus to sequence selector ComboBox as intended.
Certainly reproducible on Windows.

Feedback from jlj implied that having the ibclr close to ibrsp (which is hevily used) can lead to accidental clicks on ibclr which resets the GPIB state machine / task on the prober. A confirmation request would be useful.

This would basically mean that one never needs to touch the .conf

Due to permission issues on Windows on official TEL computers, the log might not get written.

Empty first line in sequence not handled correctly by the command processor.

gpibResponseTimeout from .conf not applied on startup
Applying it may be useful as to avoid default infinite timeouts from NI-VISA library on Windows.

Clicking Save while editing a cell does not save the cell content.
The focus must be changed on another widget so that the cell content may be actually saved on disk.

Currently, the Stop button stops the sequence execution right after the completion of the ongoing command. However, if the prober doesn't send an SRQ when the user awaits it and if large timeouts (tens of seconds) are used, the GUI is locked.

Perhaps command execution threads may be killed without consequences. It is definitely not good practice but neither is it better trying to bypass the use of hardware timers (the root cause).