LinuxCNC + Orange Pi (allwincnc)

Is there anything on the Orange Pi implementation of LinuxCNC that would prevent spindle synchronized motion for threading, either on a lathe, or maybe also on a mill for tapping?

Encoder feedback for closed loop was worked on. I have not tried it yet to see how far along he got. The only problem might be how fast can position info be passed back to the big ARM cores for closing the loop for spindle synchronization.

Also, for the lathe, I would like to put a pair of hand wheel encoders on, one for manually controlling the X axis and one for the Z axis. This would enable using the lathe like a pseudo manual lathe as well as for CNC. Would this also be possible?
 

It should not be a problem unless you are trying to hand turn and run a program at the same time with closed loop. Not that you would. In manual mode the drives are disabled so you can freely turn the hand wheels.

EDIT:  I found what I needed in some of the documentation and in this loooong thread.

BTW:  I think you misunderstood what I was talking about. My lather will not have any direct mechanical connection to handwheels.  I intend to use handwheel encoders, manual pulse generators, or whatever you want to call them to simulate the manual cranks on a lathe. They would be connected electronically to LinuxCNC and used in jog mode like the manual cranks would, but all motion would be done by LinuxCNC driving the stepper motors.

Thanks

I think this project is dead, it was never finished. I would look more at the STM build with Remora. I have an H3 2gb board just sitting if this does ever start back up.

Have you noticed that 109jb is trying to work on it and fix it?

Not so sure about me being able to "fix" anything. I'm more just trying to see where this is at and if it is usable in its current state.

That said, I have done the following:

• Installed Armbian
• Set up USB automount (Found rather quick that Armbian didn't have this)
• Installed LinuxCNC (Just used the Allwincnc basic setup directions
• Set up a WHB04B-6 wireless usb CNC pendant

Observations after the above:

• Definitely not a speed demon. Just using a web browser can crash it, but I'm not intending it for web browsing.
• LinuxCNC seems to run fine. Can avoid a reatime warning by just allowing it a few seconds to fully start before trying to do anything
• The default Allwincnc configuration is 3-axes and based on the ini and hal files is set up for 100kHz step rate.

I programmed an ESP-12E microcontroller to act as a step counter and did a bit of testing on it, but have to do more. I will test it with Grbl at 30kHz to see if the step counter is working correctly before giving results of testing with the Orange Pi LinuxCNC install. Going on vacation for a week so progress stopping for now. Will resume  on return.
 

" just trying to see where this is at" is closer to a fix vs just complaining about the project and expecting others to do the work for them.

The dev that started this project somehow expected u-boot and Armbian to just work. Thank you for spending the time to try and build it and posting your issues.

Sorry for the project freeze. I'll try to continue, but in other way. I want to make a LinuxCNC based DSP handle controller with LPT, Ethernet, and USB ports, mini display, hand encoder and physical keys. I'll use the black pill (STM32F401xx) board instead of built-in CPU to make a pulse generation (and encoder pulses counting).

Sounds like you want to help with Remora.

forum.linuxcnc.org/18-computer/42276-rem...rocontroller-via-spi

github.com/scottalford75/SKRV2-Mbed-OS5/...ain/OS5-SKRv2-Remora



Also check out:  forum.linuxcnc.org/18-computer/42414-lin...ethernet-using-esp32

I'm still planning on build u-boot properly when the hardware becomes available again for this project. A preempt_rt kernel should be no problem as well. A few of the pine64 boards use Rockchip and Allwinner ARM SOC's with integrated MCU's.

Thank you again for all your work.

Rockchip RK3399 has a few Cortex-M0 cores, Allwinner H3/H5/H6 has a single OpenRISC core, Allwinner H616 has no additional cores.. All the new (and old) chips are different. uboot, kernel and other stuff are different too. We can't catch them all to the one huge project. Much easier to make a tiny project with stable and general code base, which can be used with all chips and all mini PCs.

No, remora is not my way. I know STM32 very well. I can use all hardware features of it to make a good and fast pulses generator/counter. Already done some projects with same functionality.

A tailored U-boot for each ARM board is necessary since it is the firmware used at boot to configure the hardware properly. This is similar to the BIOS/EFI used on x86 motherboards. The firmware can keep the core clocks locked vs speed stepped in order to keep jitter low even though we are using the servo thread in this project.

A preempt_rt kernel tailored for each ARM processor also keeps jitter to a minimum and performance to a maximum.

I don't count on the Armbian devs to get preempt_rt kernel configs right. U-boot is also outside the realm of application devs. It tends to fall on the hardware devs to get it right. I'll work on this as boards become available again.

New users from other projects such as GRBL on *duinos and similar are not used to the settings required in the LCN conf and hal files. When they get following errors they don't understand how to correct them in their settings.

When the semiconductor industry settles down in the near future we should be able to have access to the Allwinner boards that use an integrated MCU. Rockchip boards have also have spotty availability currently.