Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mesa Encoder is latching quad errors when quad-error-enable is FALSE. #2860

Closed
JTrantow opened this issue Jan 22, 2024 · 6 comments
Closed
Assignees

Comments

@JTrantow
Copy link
Contributor

https://forum.linuxcnc.org/27-driver-boards/41273-hostmot2-encoder-documentation#291356

Here are the steps I follow to reproduce the issue:

  1. halrun -I halrun_encoder_test.hal
  2. Connect the input-a, input-b pins of the mesa encoder.00 together and toggle to create a quad error. This will not show up since the script leaves encoder-quad-enable FALSE.
  3. sets encoder-quad-enable TRUE.
    halrun_encoder_test.zip

This is what I expected to happen:

Should NOT trigger a quad error as the quad error is supposed to be cleared when quad-error-enable is FALSE.

This is what happened instead:

halcmd: hm2/hm2_7i92.0: Encoder 0: quadrature count error

When UI is running this will pop up a dialog. On my machines using single ended glass scales the quad error occasionally pops up the first time I set quad-error-enable TRUE. I have the quad error triggering an estop and when I clear this, I can proceed. I can pulse quad-error-enable (before estop) but I still get the quad error dialog from hostmot2.

Problem has been around a long time.

I first noticed it back in 2021 but I did not understand exactly what was going on and just lived with the inconvenience of an occasional extra estop reset during startup. Fixing this bug would allow quad error detection to ignore any startup transients.

Information about my hardware and software:

Description: Debian GNU/Linux 12 (bookworm)
Linux debian 6.1.0-16-rt-amd64 #1 SMP PREEMPT_RT Debian 6.1.67-1 (2023-12-12) x86_64 GNU/Linux
Binary from 2.9.2 iso.
Occurs with Mesa 7i92+7i85S and 7i96+7i85S

@andypugh
Copy link
Collaborator

@pcw-mesa Do you agree that this is wrong behaviour?

@pcw-mesa
Copy link
Collaborator

Yes, it's a race/sequence error in the driver and I can duplicate it.
Looks like a trivial fix, I'll try and get it fixed sometime today or tomorrow.

@pcw-mesa
Copy link
Collaborator

Should be fixed: 4d0e948

@andypugh
Copy link
Collaborator

This fix has gone into master. Should it also be in 2.9?

@andypugh andypugh reopened this Jan 23, 2024
@pcw-mesa
Copy link
Collaborator

Yes, just pushed in 2.9

@andypugh
Copy link
Collaborator

Thanks

@JTrantow JTrantow mentioned this issue Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants