Requirement for encoder.<n>.reset (HAL_BIT) about litex-cnc HOT 17 CLOSED

You were correct: the reset-mechanism was not working. Solved it.

Longer explanation:

• when the reset is HIGH the current position is stored;
• the position is then subtracted from all subsequent positions received from the FPGA.

One way or the other: I forgot the second step 👎.

If you could test again:

• install with the latest commits: pip3 install git+https://github.com/Peter-van-Tol/LiteX-CNC@73-requirement-for-encodernreset-hal_bit
• reinstall the driver: sudo -E env PATH=$PATH litexcnc install_driver

It should have reset function now. Also tested it on my machine, with positive results.

from litex-cnc.

Thanks for your quick test. Based on your log I will track the error down. To. Tomorrow evening I will have this sorted out.

from litex-cnc.

Whether the axis will rapid back to zero depends in your hal-configuration and the order of the components. I think that I will include the functionality, as the encoder module is designed as a drop-in replacement of the LinuxCNC version (which is designed for a LPT-port). This version from LinuxCNC has the same possible danger in it.

No reset needed for ANGLEJOG
I was not familiar with the function ANGLEJOG, so I checked the source code. It allows you to jog to axis simultaneously at a certain angle. While reading the source code I found that you don't have to reset the counts! The code works with a delta between counts of the previous step and the current step.

To make this work without resetting:

• make sure to always update the counts-in pin of the ANGLEJOG component;
• only enable the component using enable-in when the selector is in the correct setting;

This component more or less behaves as a normal jogging command. It internally updates the counter only on the difference between current count and last count when the counts-in is TRUE.

Possible solution for a safe design when you need to reset it for jogging:
To reset the counter in a safe way, you could use an AND between the reset-pin and the jog-enable. If the MPG is being reset, the machine will not be jogged. When the reset is LOW, the counts are stable and the jogging will resume. The order of the components / functions is important:

1. Read the FPGA;
2. Determine whether the encoder should be RESET;
3. Determine jog-enable (AND with RESET)
4. Motion planning (jogging is done here
5. Write to the FPGA

This will result in the following cycle:

1. Read the FPGA -> the encoder is not reset yet, but the axis to be jogged has changed to the rotary axis;
2. Because the axis has changed, the counts of the encoder should be reset
3. Because the reset is active, jogging is prohibited
4. Motion planning: won't move as jogging is not enabled
5. Write to the FPGA
6. Read the FPGA -> the encoder counts value is set to 0 now;
7. The axis didn't change, so the RESET will be low
8. Jogging is enabled
9. Motion planning will jog the relative rotation
10. Write to FPGA

from litex-cnc.

Is resetting required in the FPGA, or would s 'soft' reset do the trick. The implementation of the soft reset is to add an offset to the encoder. When the reset button is clicked, the current value of the raw counter is stored in the offset. The reported counter would be raw counter - offset.

Prossible problem with doing it in the FPGA is that the data is read, then written. Between the decision to write data and actual reset some pulses may have been seen and they will get lost because of the time between reading and writing.

Just put of curiosity: what are you building? And would you have an index pulse available (in which case it can be done already in the FPGA)

from litex-cnc.

Building a MPG with independent X & Z jogging and the linuxcnc component Anglejog on the same MPG. The A axis knob selector enables anglejog, but when I'm changing mode with that knob, the axis rapids to a 'scaled' count of the encoder.counts.

I've since created an additional set of IN/OUT pins in python that feeds offset counters individually (soft reset?). One for the X & Z, another for Anglejog. This to say my counter reset issue is solved with HAL, bit of a mess though.

I was asking because I've read it's avail on mesa firmware, and so I thought it was something standard across but yet completed in Litexcnc given the pin is already visible. That pin would have cut off a lot of coding and overheads for instance...

Leave it to you to decide whether we need that reset pin. I personally think we do but it's your call man

from litex-cnc.

Closing this since you've read. Open for conversation in the closed area if required, once you've established whether we need count reset, or not! Cheers, Peter, and all the best to you.

from litex-cnc.

Reopening this as issue, because there is a possible non working HAL pin.

Thank you for sharing the use case and rationale.

from litex-cnc.

Proposed changes:

• add raw_counts property, which reflect the number of counts currently held in the register of the FPGA
• modify counts property, which will be reset when the reset pin is HIGH in the HAL. Resetting the counts property will also affect position
• the reset pin will be I/O. After resetting is done, the pin will be set LOW.

This change will not affect any current user. It only adds a functional reset pin.

from litex-cnc.

@GTCLive : would you be able to test this change somewhere next week?

from litex-cnc.

This feature has been finished. Before merging, if anyone would like to test this, you can try:

pip3 install git+https://github.com/Peter-van-Tol/LiteX-CNC@73-requirement-for-encodernreset-hal_bit

And run litexcnc install_driver to have a working rest-pin.

from litex-cnc.

Peter, I'm honored to be able to test this. Let me see if I can sneak out from home this Saturday, I'll garage myself for a trial. That's awesome btw, and sorry for the delay in responding.

from litex-cnc.

Decided to give it a trial real quick, but it failed to start Linuxcnc for some strange reason I wish I had the capacity to explain. Attaching the error trace, I'm pretty sure it will make sense to you. Steps taken below:

$ cd /home/cnc/LitexCNC/
$ source /home/cnc/LitexCNC/bin/activate
$ pip3 install git+https://github.com/Peter-van-Tol/LiteX-CNC@73-requirement-for-encodernreset-hal_bit
$ sudo -E env PATH=$PATH litexcnc install_driver
$ litexcnc build_firmware /home/cnc/LitexCNC/GTC_firmwares/5a-75e-80_gtc.json --build -a
$ sudo /opt/oss-cad-suite/bin/openFPGALoader --unprotect-flash -c ft232 -f /home/cnc/LitexCNC/GTC_firmwares/5a-75e-80_gtc/gateware/colorlight_5a_75e.bit

$ cd /home/cnc/linuxcnc/configs/GTC_LATHE/
$ linuxcnc GTC_LATHE.ini

Restoring the 1.2.0 version and reinstalling its driver makes the machine run normally again.
$ pip3 install litexcnc==1.2.0
$ sudo -E env PATH=$PATH litexcnc install_driver

Awaiting your next command! Good luck.

Error log: Litexcnc_1.2.1.txt

from litex-cnc.

@GTCLive : could you share your config with me? I've trouble to reproduce your error. Maybe it is due to a certain combination of modules. Also, my tests run in halrun not in full LinuxCNC. Could you also share your HAL / INI files?

from litex-cnc.

Much obliged Sir. I attach a stripped down Linuxcnc config & hal which is error-free and work toward @73-requirement-for-encodernreset-hal_bit. The only addon in this config is a simplified mpg to test the encoder0 counter and reset pin.

However, as you can see from the screengrab, the reset pin will not reset the counter as you've anticipated. Setting the pin back to LOW (clr) neither reset the counter. Or perhaps I am the wrong person for testing a situation like this one (personally I think I'm the wrong person, particularly when it comes to linux and relevant).

Note: The Watchdog has bitten error is irrelevant and can be ignored. This is an old bug from 1.2.0. It occurs once on twice restart. E.g. close linuxcnc, restart it and the error occurs. Close it again and restart, the error disappears.

GTC_LATHE Config: GTC_LATHE.zip

from litex-cnc.

You cannot imagine how much I value your contribution and testing. I will give it another try this evening.

from litex-cnc.

Yeah man it works. Wow.

However I think I know why you've initially left that reset pin null now (smart). If the counter is reset, in the case of a mpg (for instance), the axis will rapid back to zero unannounced when that count is zerod. The enhancement is adaptable and useful in my case, but for someone else it could become incredibly dangerous. Use/Reset with extreme caution!

That's one of those thing. As previously said; you're the one who calls on whether everybody needs it.

from litex-cnc.

That's beyond awesomeness of your part for having taken the time to look into this, Peter. Thoughtful thinking in where and how to use the reset pin too. Much appreciated, I'll revise the work I've done and see how I can make it better.

On the testing part I can say that it works at my end. Do let me know if you need me to carry out other tests I'll be happy to give this a go, despite limited abilities. (ps. your knowledge is incredible btw!)

from litex-cnc.