MotorSpinBoxBrick: move motor while button pressed

[natxo14]

Hi all,

I'm trying to make MSBB's left and right arrow buttons work as 'press' buttons ( make motor move while button is pressed).
Following Qt documentation ( https://doc.qt.io/qt-5/qabstractbutton.html#autoRepeat-prop ) I added some properties to buttons and with 'oneClickPressButton' property I change their autoRepeat property:

self.move_left_button.setAutoRepeat(new_state)

The problem comes from the fact that buttons are disabled and enabled with the HWRObject's state changing: buttons are disabled while the motor is BUSY/MOVING. And it seems that when the button gets disabled, then it 'looses' the "pressed(), released(), and clicked() signals that are emitted at regular intervals when the button is down.

If someone knows how to avoid this signal disconnection, I'll be glad to hear the solution.

So far I've found two 'solution' ( I not sure if they deserve that name ):

• If the user (with the mouse button still pressed over the button) moves slightly the mouse after the button gets enabled back, then pressed signal will be received again.
• Avoid to disable buttons when state==BUSY : this could sound dangerous, but the function launched when button clicked ( move_up/down) don't act in motors unless the state is equal to READY.

A minor problem, no urgent at all. Maybe I just wanted to open my first issue on the project.
Maybe it would be easier to change the Tool tip of buttons, as they announce this functionality that is not (still) working :)

[vrey01]

I do not see a problem to keep a simple logic without artifices, or maybe I am being too simplistic

Is there anything wrong with the following?

logic (for move_while_pressed)

   1. press happens and it is ready --> start moving
   2. press happens and it is not moving --> is should be already disable anyway. (case 8 below)
                                          in any case (even if it in principle not possible).. ignore press

   3. release happens and it is moving --> disable (but movement will finish... or do you want to stop it?)
   4. release happens and it is ready --> nothing to do

   5. state changes to ready and it is still pressed --> start next movement
   6. state changes to ready and it is not pressed --> apply logic of enable / disable

   7. state changes to moving and it is pressed -->  keep it enable
   8. state changes to moving and it is not pressed --> disable

implementation of the logic

def state_changed(motor_ready)

   state_ready = motor_ready

   if move_while_pressed and is_pressed:
       if state_ready:
           start_next_movement
       return # keep it enable

   if state_ready:   
       enable()
   else: 
       disable()  #  moving, fault...

def button_pressed()
if state_ready:
is_pressed = True
start_next_movement
else:
pass # ignore press if not ready

def button_released()
is_pressed = False

   if not state_ready:
       # if condition on move_while_pressed could be added but unneccesary
       # disable always if moving and released
       disable()

[natxo14]

Kaixo Bixente, and thanks for your reply!

Correct me if I'm wrong, but I guess there's a typo in point 2:

2. press happens and it is not moving => 2. press happens and it is moving ( this links better with point 8)

So, my concerns where about the point 7. Following your explanation, if button remains enabled when motor moving and button pressed, then my issue is gone :)

Concerning your question on point 3:
3. release happens and it is moving --> disable (but movement will finish... or do you want to stop it?)
My answer would be to let the movement (of 'step' amplitude) to stop by itself, but maybe I'm lacking experience to detect a possible danger.

Thanks!

[vrey01]

Natxo ! Yes. You're right. That was a typo on case 2.

If if was my choice, on point 7, I would rather let the movement finish on "release". I do not think there should be any danger in that.

Still, if the idea of the feature is to use "press/release" to help in searching some kind of event to happen (visual aligning, maximum counts...) the "stop" should then be as close as possible in time and distance to the "release" of the button. If the step-size is relatively small that will still be fine but... discuss with your scientists, you may consider to call "stop" on "release" after all.

Remember too that for a precise aligning they should use a fine "scan" anyway.

ez horregatik ;-)