LinuxCNC + Orange Pi (allwincnc)

More
07 Jun 2021 18:40 #211433 by PCW
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.

Please Log in or Create an account to join the conversation.

More
07 Jun 2021 18:54 - 07 Jun 2021 19:01 #211434 by mwidlok
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 :-).
Last edit: 07 Jun 2021 19:01 by mwidlok.

Please Log in or Create an account to join the conversation.

More
07 Jun 2021 18:55 - 07 Jun 2021 18:56 #211435 by mwidlok
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).
Last edit: 07 Jun 2021 18:56 by mwidlok.

Please Log in or Create an account to join the conversation.

More
08 Jun 2021 00:40 #211467 by PCW

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)

Please Log in or Create an account to join the conversation.

More
08 Jun 2021 04:27 #211481 by MX_Master
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 :)

Please Log in or Create an account to join the conversation.

More
08 Jun 2021 11:02 #211497 by mwidlok
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.
The following user(s) said Thank You: MX_Master

Please Log in or Create an account to join the conversation.

More
08 Jun 2021 11:09 #211498 by MX_Master

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

Please Log in or Create an account to join the conversation.

More
08 Jun 2021 18:42 #211534 by mwidlok
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).
Attachments:
The following user(s) said Thank You: MX_Master

Please Log in or Create an account to join the conversation.

More
10 Jun 2021 14:56 #211704 by Bari
And another story about it here: 3D printer board runs Linux on Allwinner A64

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

Please Log in or Create an account to join the conversation.

More
12 Jun 2021 07:17 - 12 Jun 2021 07:25 #211857 by tjtr33
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 added
extraargs=isolcpu=1,2,3 idle=poll
to 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
Attachments:
Last edit: 12 Jun 2021 07:25 by tjtr33.

Please Log in or Create an account to join the conversation.

Time to create page: 0.125 seconds
Powered by Kunena Forum