LinuxCNC + Orange Pi (allwincnc)

Hi envyvan,
Today I was milling and I again got the same error two times. I thought it was caused by adaptive cleaning G code algorithm from HSMWorks, but then I was manually moving (by keypad) with axis and I got the same error
I have only passive heatsink on CPU so I am going to try add a fan.

I am using debian - buster, release 10. Maybe I need some system optimize.
Servo-thread.tmax I had about 1000000 during the milling process.

Can you tell me what to change in ''settings'' ?

M.

Hi Mlc,

I don't have any luck to make the mesa driver installed on debian buster.
I did some research before, you can see link below for reference:
www.forum.linuxcnc.org/18-computer/39037...cnc?start=310#217178

I think I also upload my SDcard image somewhere. it was base on ubuntu.
If you get interest, you can give some try on it.

I think Servo-thread.tmax above 1000000 might cause some issue. You should keep your Servo-thread.tmax number below 1000000.
Try to disconnect you cable network and wifi.
Backup, your sdcard.
Then check your system"Session and startup", make sure no any unnecessary program there. I think we don't need any of auto update stuff.

mwidlok wrote:

Just an update - while playing around with spindle I found that, I am missing spindle-index signal (my encoder does not have this functionality). I've add a simple patch to arisc.c driver (for H3) that can emulate index.

This patch just zeroes position and reports back to hal that index arrived - I am NOT SURE if this is right, but it seems to work for me. Please check it!!!
That was completely wrong. DO NOT use simulate_index.patch, use simulate_index_v1.patch file!!
Now simulated index always waits for next full revolution before clearing spindle position and sending back index signal to HAL. In this way our virtual index fires at the position that spindle was at linuxcnc startup.

Patch file and HAL config are attached here. To use simulated index just set "arisc.encoder.X.simulate-index" parameter to 1, then connect spindle.X.index-enable in normal way.
 

File Attachment:

File Name: emco_PC_sp...9-26.hal
File Size:1 KB

 

File Attachment:

File Name: simulate_i...v1.patch
File Size:2 KB

mwidlok wrote:

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).
 

Hello!
Can you look at the encoder velocity?
I have a configuration for a lathe, but i need to scale RPS to 60 000 000 to have a "correct" spindle-at-speed. and the RPM change range only 25 RPM on the encoder. If I command 240 RPM the encoder velocity is showing 225, or 250 (if speed up, the next will be 275, 300, 325 and so on)
In %  to reach the spindle at speed I need to change the value from 1.01 (to be  in 1% of error) to 1.5 (50% error) in the .hal to get green light. On slower speed is worst... (I will use a servo drive encoder output - 13 bit = 8192 in LCNC scale)
Is it possible to correct it some how?
 

Hello, seniors,
       I have an OPI now, but I feel that its GPIO interface is not enough for the things I want to control, such as the five axes. It may not be enough to add some limit return and stop switches and handwheels. So I want to ask if OPI supports etehrcat? I have several EtherCAT drives. I don't know if OPI supports them. I used to use x86 to control drives with Linux CNC and IgH EtherCAT.
     If someone has done it, or can give me some help, I will be very grateful.

The original maintainer of this project has stopped development. You are free to fork it and add features like EtherCAT.