motorRecord.cc: Jogging against to LVIO in LVIO

[tboegi]

No description provided.

[tboegi]

How to reproduce?
Press JOGF, wait until the record stops the motor, close to HLM.
Press JOGF again.
Look at the MIP field. In my case MIP was not 0, but JOG_REQ was still on.

[tboegi]

Note:
The record does not lock up, so that the commit msg is wrong.
The JOGR/JOGF field stay 1, and need to be reset to 0 to "unlock".
I will send a new version, in some weeks or so.

A test was added here:
https://bitbucket.org/europeanspallationsource/m-epics-ethercatmc/src/6f71147bec5b35f326b4e3097f2a97fe6c193fa6/test/nose_tests/121_Record-JOGF_DLY_HLM.py?at=torstenb%2F180629_dev&fileviewer=file-view-default

[kmpeters]

Note:
The record does not lock up, so that the commit msg is wrong.
The JOGR/JOGF field stay 1, and need to be reset to 0 to "unlock".
I will send a new version, in some weeks or so.

Is the new version just to correct the problem description? If so, that isn't necessary. I can just make a note in the merge comment.

[tboegi]

I would love to have the commit msg to be in sync with the problem description.
Right now it isn't, so please let me submit a better commit.
And thanks for offering help

[kmpeters]

Sounds good.

[tboegi]

Now I updated the commit message (with a forced push)

[kmpeters]

I wasn't able to reproduce the non-zero MIP when attempting to jog into a limit after a limit violation occurs, but I did confirm that the JOGF/JOGR fields weren't immediately reset when the limit violation occurs.

With the change in the pull request the JOGF/JOGR fields get reset to zero when LVIO goes to one. If a user was holding down a jog button on a MEDM screen, this means the JOGF or JOGR field will be set to zero a second time when the button is released, but this shouldn't have any negative consequences.