Can the OPI5 be Configured to Run LCNC?

Solved the "failed to read" errors. PCW, a moderator here, suggested doubling the servo period, and cutting the P term on each motor in half. Didn't have time run extensive tests, but it got through the 3D_Chips example ngc file. Before, it would throw the error before completing two lines.

I reading in another thread that there my be a kernel fix to make the long servo period unnecessary.

If you are getting an "Error Finishing Read" it means the network latency exceeds the available time in the servo thread a few times in a row. So you can have the fastest latency in the world but if the NIC is not up to the task you will get errors. This is more prevalent with Realtec NIC's
sudo ethtool -i  eth0 may give some clues to the NIC on the OPI (where eth0 is the NIC name returned by ip a)

Network latency first became an issue on kernel 5.1 and continued to improve with each kernel version.

​​​​​In summary, perhaps Bullseye was not an ideal choice. As a minimum, I would rebuild using Bookworm (Deiban 12) and it's 6.1 kernel (or higher)

For more information, about the problem, it's covered in the 2.9 docs I wrote here linuxcnc.org/docs/2.9/html/getting-start...ltek_network_drivers

Well, the solution isn't the best. Doubling the servo period will slow the machine down. I looked into updating the RealTek network drivers, but it OPi5 uses a YT8531 chip.

Maybe there is a setting that can improve the perfomance of YT8531? If not, I'm thinking that a 2000000 servo period is the best we're going to be able to do with an OPi5

echristley wrote:

Well, the solution isn't the best. Doubling the servo period will slow the machine down. I looked into updating the RealTek network drivers, but it OPi5 uses a YT8531 chip.
 

I was not intending you attempt to follow the realtek path but i you investigate the NIC and the driver in use as I suggested, you may get some clues. But it will be a kernel issue so updating to a later kernel will help.

Another note, the OPi5 is sensitive to heat.
Set the servo to 1200000 and the P to 833 and ran a couple of the example programs. No problem. I left the system up while I went in for dinner. Came back out intending to run a couple more, but it just failed to complete the reads. Reset the servo to 2000000, and still got the read errors. Didn't have a small fan ,to I put my big shop fan to blow on it. Cooled it right down, and the read errors disappeared.

The Opi5 can run pretty cool, with 2 cores isolated and a good heat sink it takes some time before it begins to throttle.

I wonder if it was because of throttling or might one of the other chips get overheated? Ethernet chip or PMU?

You could check the cpu temp with armbianmonitor -m

Did you try to set the servo back to 1000000 with the big fan on it?

No. I didn't try that. I'll do that tonight. I don't think it likely to succeed. The failures happen early on after boot-up before. But, it is easy to do.

Not sure if this applies to the OPI5 but typically you cannot have any kind
of CPU speed modulation enabled with real time operations as the CPUs is
often halted for milliseconds when stepping between speeds.

The same with the OPI5, it's disabled in the kernel config. I assumed it would still throttle as a safety, but you are right. Forgot I had tried that once without a fan or heat sink but 2 cores isolated, at 85 celcius degrees (max temp) it still didn't throttle. That could also give problems.

If echristley still has these issues while cooling I'll try to reproduce the error.

Picture of the setup.  Motors on top, beside the monitor.  White box on the right with the scope sitting on it is the power box.  Fan is blowing directly on the OPi5.

I moved the servo period to 10000000, and the P factor to 1000.  Opened up Gmoccapy and loaded the "cds" example file.  Before it got the bit into position to do the first cut, it failed to read.
Shifted to 1500000 (how ever many zeros that is supposed to be).  Ran the same example file, and got maybe halfway through.