LinuxCNC + Orange Pi (allwincnc)

Actually you should always use period for velocity calculations as even at higher speeds you throw-away velocity resolution if you don't take the period into account.

I was thinking about really high input frequencies. Right now risc loop can see changing pins up too about 300kHz. Using it to calculate period at 200kHz input would result in even worse resolution then now.

What frequency range we get from encoders in real-live is another meter - I have no experience here .

PS.
Thanks MX_Master for explanation about risc firmware! I will try to set up compiler and build Yours driver on my own (mostly for fun now).

mwidlok wrote:

I was thinking about really high input frequencies. Right now risc loop can see changing pins up too about 300kHz. Using it to calculate period at 200kHz input would result in even worse resolution then now.

What frequency range we get from encoders in real-live is another meter - I have no experience here .

Yes, it depends on the resolution of the timestamp but the idea is to get velocity from the counts/time_between_counts
(which will be close to 1 ms but calculated from the time of the first count to the time of the last count per period rather than
just the delta time which will have a full count uncertainty)

Velocity meter of the driver is totally untested. So we have some work to do.
Performance of the pulses counting/generating (firmware) is upgradable too

I've just add simple period measurement for encoder module on H3. It seems that I would be able to do it in "proper" way and return real velocity to HAL.
If You want I can provide a patch in short time, however I don't want to duplicate effort if someone working on it already. Please let me know, if You are interested in my updates.

mwidlok wrote:

I've just add simple period measurement for encoder module on H3. It seems that I would be able to do it in "proper" way and return real velocity to HAL.
If You want I can provide a patch in short time, however I don't want to duplicate effort if someone working on it already. Please let me know, if You are interested in my updates.

You can add a pull requests to the repos

Sorry, I'm not working with git much - after a few tutorials I'm still not sure how to create a valid pull request. Please check the patch files from this message.

I've added new output to HAL (period_ticks) for testing the ARISC code. It is pin A period in raw timer ticks. Then the hal driver calculates velocity from period output, until about 110kHz when it switches back to frequency. Of course this is rather poor, and we should use method described by PCW. Anyway this code seems to work orangePi H3 (the only board I have).

And another story about it here: 3D printer board runs Linux on Allwinner A64

linuxgizmos.com/3d-printer-board-runs-linux-on-allwinner-a64/

I rcvd 2 OPi+2e's yesterday in Thai Post. The box was crushed, but the 2 boxes inside that seemed ok.

The 1st got Armbian Buster and it ran the AllinnerCNC script fine. I addedto ArmbianEnv and stuck the cpu speed to 1008. It ran well.

The 2nd unit refused to boot the same SD card until i cleaned te SD card slot with 90% alchohol. Then I got green led immediately and it ran fine. Prior symptom was red led, then green, then red, then Android set-top box in Chinese.

I do have an H5 for the future

RE: SD card detection:
Do this test of SD insert-detected switch with nothing connected and not powered!
Pin 9 to metal cover(gnd) will show continuity when card is inserted, and open without.
Pin 1 will have arrow on silk screen. Pin 9 is last. ( did you know these SD acrds are SPI devices?).

Phew!

BTW Shenzen Xulong ( seller and manufacturer wre communicative, and suggested tryin the boards and that I could open a dispute if unsatisfied. Of course I didnt need thier permission, but they suggested opening the crushed box and examining the boards.

A note about old USB ports:
Many of us use old pc's and the USB ports are not meant for lots of insertion/removals. If you have problems creating SD cards for these micro-computers ( Pi BB etc). and have USB in the hardware chain used to burn the image. Look at wether the plug to jack feels solid and resists removing the cable. There's 6 on my ancient P2 box and most are sloppy.
Hint: if the SD card appears and disappears from desktop as you move cables, this caution is for you.
Dmesg will also show disconnects.
At first I thought a power usb port fixed it, but no, it returned when I made this most recent SD card.

tomp