LinuxCNC + Orange Pi (allwincnc)
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.
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?
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.
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?
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.
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
- 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.
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.
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.
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 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.