LinuxCNC + Orange Pi (allwincnc)

mwidlok wrote: What is the status of "encoder" module for H3?

I'll try to fix all errors as soon as possible

Thanks MX_Master.
Anyway while I understand (more or less) how the driver + arisc firmware works I am completely missing place where the arisc firmware is loaded to the processor. Could You please explain it a bit? I think that I might be able to help with some minor bugs if You want.

mwidlok wrote: Thanks MX_Master.
Anyway while I understand (more or less) how the driver + arisc firmware works I am completely missing place where the arisc firmware is loaded to the processor. Could You please explain it a bit? I think that I might be able to help with some minor bugs if You want.

A simple u-boot script (for H3) uploads the firmware to the target SRAM address and starts the ARISC core via special register

github.com/allwincnc/installer/blob/mast...bian/fw/h3/fixup.cmd

This trick works only for H3. The H5 needs a kernel module to upload and start the ARISC core. And none of these tricks works for H6 H6 needs another secure method of memory editing

3D printer board leverages Allwinner A64’s AR100 core for real-time control
www.cnx-software.com/2021/06/05/3d-print...r-real-time-control/

github.com/intelligent-agent/Recore

github.com/intelligent-agent/Refactor

wiki.iagent.no/wiki/Recore

www.iagent.no/2021/06/04/recore-is-finally-printing/

We can "fix" their project to run LinuxCNC on the A64

I have a hard time accepting that they spent two years just to run Octoprint and Klipper on this vs LCNC. Why?

Doogie wrote: Did you guys see the Recore project which uses an Allwinner A64? I just learned about it and found out that the Allwinner A64 has an onboard micro controller, an AR100(OpenRISC) cpu which the Recore people put Klipper on for doing stepgen. Klipper is only for 3D printers though. If we got Remora onto that AR100/OpenRISC processor then LinuxCNC is your uncle for everything from CNC, 3D printers and laser cutters. Welp, Scott Alford just reminded me that MBed is only for ARM chips and Remora is built on MBedOS so porting it to the OpenRISC/AR100 wouldn't be an easy task. Darn, the versatility of full LinuxCNC on Remora(or Mesa) is the bomb.

This project (allwincnc) can be used on A64 boards too. A64 it's a H3 with tiny changes But I never tested it on A64 (has no such boards). The firmware (allwincnc, AR100, OpenRISC, ARISC) is already fully optimized for the fast realtime tasks, no need to port anything.

MX_Master wrote:

mwidlok wrote: What is the status of "encoder" module for H3?

I'll try to fix all errors as soon as possible

All the general bugs were fixed. Tested with simple 80PPR encoder. mwidlok, you can continue.

Any other people can join the testing Driver docs are here - allwincnc.github.io/docs.html . Simple HAL file to test a single encoder is here - github.com/allwincnc/linuxcnc/blob/maste...isc-encoder-test.hal

I see the encoders talked about a lot, this is really only for servo systems right? If im running a stepper or closed-loop servo looped only with the drive then encoder inputs are irrelevant correct? or is the stepper signal feedback through an encoder to verify stepper count?

Cncninja wrote: I see the encoders talked about a lot, this is really only for servo systems right? If im running a stepper or closed-loop servo looped only with the drive then encoder inputs are irrelevant correct? or is the stepper signal feedback through an encoder to verify stepper count?

High resolution encoders and linear encoders uses for the DIY high accuracy realtime position feedback (closed loop). Medium resolution encoders uses in mechanical handles. Small resolution encoders uses in some control panels to increase/decrease spindle RPM, cutting speed, etc.

Cncninja wrote: I see the encoders talked about a lot, this is really only for servo systems right? If im running a stepper or closed-loop servo looped only with the drive then encoder inputs are irrelevant correct? or is the stepper signal feedback through an encoder to verify stepper count?

Encoders are fed back to LCNC to keep track of the position of any joint or axis.

Closed loop steppers where the loop is closed in LCNC.

Servo systems can also tie the encoders back into LCNC to close the loop so that LCNC keeps track of the machine position and speeds.

Spindle synchronization using an encoder on the spindle for things like rigid tapping.

Synchronization of all sorts of mechanisms in LCNC using encoders such as lasers, plasma cutters, inkjet heads, etc etc

MX_Master,
Thank You for update, I've just tested new drivers with generator. I'm using very similar configuration to Yours example (one input pin, simple counter mode, no reset), and HAL Meter.

Position calculation is correct up to about ~300kHz (50% with duty cycle, great), however the velocity is very wrong. Looking at the code I think that I can see the problem, please check my findings:
1. It seems that the line 974 in arisc.c is wrong there. We should update ep.counst only when we perform velocity calculation.
2. Velocity formula should be:
vel = (eh.counts - ep.counts) / scale * 1e9 / no_counts_time;

While results are correct with this method, it gives very poor resolutions at low input frequencies. At 1ms servo period, 1kHz at input gives velocity = 1000 (scale=1), 1.5khz gives 1000 or 2000 (fifty fifty). Proper method would be to calculate period of input encoder signal at low frequencies and frequency at high. Alternatively we can just increase number of counts needed to perform calculation, but this would decrease update rate.

I don't know how important for linuxcnc is velocity signal anyway, I don't have my machine yet. I'm just testing my stepper/spindle driver now, with floating motors.