qtepics / qeframework

epics Qt has been spilt into a number of components. This project provides the framework library and standard widgets.
GNU Lesser General Public License v3.0
20 stars 11 forks source link

QENumericEdit does not work properly with Galil Motion Control PVs #4

Open AbdallaDalleh opened 6 years ago

AbdallaDalleh commented 6 years ago

OS: CentOS 7.4 64-bit Framework version: Could not recall the cloned version but this is the last commit on the git log https://github.com/qtepics/qeframework/commit/0677b529dddc8b61c8be6d4cf6551ffa81dff016 (Most likely tag 3.5.1)

When a set PV assigned to the QENumericEdit widget, I get always 6 extra leading zeros and 5 precision zero digits despite whatever I set the values of "leadingZeros" and "precision" properties. The PVs that I encountered before I stopped working:

  1. HLM and DHLM
  2. VAL and DVAL
  3. LLM and DLLM
  4. RLV
  5. TWV
  6. OFF
  7. VMAX

If I set those PVs to a QELabel, the value is displayed fine and If I set the VAL or DVAL PVs to a QENumericEdit the value is also displayed fine.

Another issue with QENumericEdit is that CTRL+C and CTRL+V does not work but right click > copy work. These shortcuts work on the other widgets.

pozara commented 6 years ago

While you can set leading zeros and precision, the widget by default checks for the actual range of the PV and decides based on that what the minimum number of leading zeros and what the minimum precision is. So if your motor goes from -100000 to 100000 EGUs and your MRES is 0.0002, you'll end up with 6 leading zeros and 4 decimal places. If that was not the case you couldn't cover the whole range of movement. The proper way to solve this is to set sensible limit values and MRES in motor record or have proxy PVs. However you can also un-check "autoscale" property of QENumericEdit widget which will ignore your PV values and only look at the values of leading zeros, precission, minimum and maximum properties defined for that widget.

I'll get back to you about the CTRL+C and CTRL+V.