Advanced Search

Aciera wrote:

Hm, not quite sure what to think about this but the pure lack of reaction to those individual mails about broken infrastructure makes me wonder about the state of things. Seems to me that the number of mails on the developers mailing list has generally dropped substantially over the last few months and a lot of mails seem to go unanswered.

I have been wondering about the state of things as well. I am unsure if it's ever been this slow before, but it seems most of the effort is in translating the docs. Which on one hand is a good thing, and on the other hand, we have other issues like being limited to 3 axis look ahead...

Unsure what to make of it really. Maybe it'll come back around...

More piccies from different angles. Slowly working out the cable and hose routing. Bleh. 

 
 





 

i set everything at @ 2,000 micro steps and cut another test piece. The finish seen no real difference in cut quality, but the current settings were a lot more responsive. so that part makes sense. the X axis seems to work really smooth, and the tandem Y runs better but still needs some more help.

Are there any tip or tricks for getting a tandem axis tuned? it seems like it is a lot harder to get settled into.

Thank you, this could be helpful

It's no too bad actually. I started with a working AXIS configuration and created my Probe Basic config from that following the instructions available in the sticky thread here on the forum.

it wasnt, i homed it in gmoccapy and probe basic still had no movement. i read there are files to copy and then hand edit. my brain started smoking while reading all of it so i had to stop.

These results are from my tests with the OrangePi 5 Plus and OrangePi 5 Max using the kernel patch (version 5.10.160) from your Google Drive.

I attempted to patch kernel 6.1 with PREEMPT_RT patches but couldn't achieve the same low latency levels

Is the machine homed?

Unlike Axis you can't jog the machine in Probe Basic unless it has been homed first.

For us that are new here in the community, where is the buildbot located and which users have the access required to fix it?

This is my first post on here so if this is posted in the wrong place please let me know. 

While doing research into machines with good latency numbers for use in parallel port-based step generation I keep seeing discussions about using older enterprise hardware to get good latency numbers. After seeing that most of these systems are from a decade ago I wanted to conduct some experiments to try and find a combination of new components that are able to create a system with low latency for use with parallel ports. 

I have a large collection of DDR3 and DDR4 era machines to work with so I thought that it couldn't be that hard to find a modern solution for the latency problem. I had seen on this form in a few places where AMD Ryzen CPUs were not able to create latency numbers low enough to be useful but I had not seen anyone explore using the few non-hyperthreaded Ryzen CPUs. 

After a few months of trying different configurations, a pattern started to emerge with the non-hyperthreaded Ryzen CPUs. When they are run in Core Leveling Mode set to 2 Cores per Processor their latency numbers are greatly reduced. This effect can be compounded by isolating CPU cores 0,1,2 in the 4-core Ryzen CPUs. The results from doing this decrease the latency so much that I thought it would be worth posting here for those trying to build a new system for Linuxcnc. 

If this effect applies to all non-hyperthreaded Ryzen CPUs then there are significantly more possible combinations that need to be tested. I only was able to test what I had on hand which was the Ryzen 3 1200 and 2300x, but both machines showed this trend to some extent. If there is someone else who can verify that this is not some one-off instance of this effect let me know.   

The pictures below are from this machine: 
CPU: AMD Ryzen 3 1200 w/ Stock Cooler
GPU: AMD Radeon R5 430 2GB GDDR5
MotherBoard: ASUS Prime B450M-A II 
Storage: 970 EVO 250GB - NVMe PCIe M.2
Ram: G.SKILL Ripjaws V Series 1x16gb in DIMM slot 2  
Power Supply: Thermaltake Smart 500W 80+
PCIe Parallel Port Cards: StarTech.com 1-Port Parallel PCIe Card PEX1P2
OS: LinuxCNC 2.9.3 Debian 12 Bookworm PREEMPT-RT ISO
Kernal: 6.1.0-23-rt-amd64

All Gixgears instances were run in full screen for the full duration of the histogram. 
The Latency Test shows the results after running the Geekbench 6 stress test. 

If there are any questions about this setup or configuration I'll be here to answer them. 


 

ok, card is in, screen resolution set properly, probe basic opens, i hit estop and start, but i get no movement out of any axis. gmoccapy works fine. ideas?

Thank you.



I dont know, why it is not working here:
github.com/LinuxCNC/linuxcnc/actions/run.../30146714882?pr=3113

Non-existant user wrote:

buildbot.linuxcnc.org/buildbot/waterfall
plenty of empty space there
And this is the last log i could find (there is 2.8 and master, so 2.9 is master, makes me think old logs ?!?! ) is here, all error are from pendant related stuff
buildbot.linuxcnc.org/clang/master-rt/v2...gcFORg.ii.stderr.txt

EDIT:
Ignore the error report with pendant stuff, it is from 2021, but it is the last clang log present on that buildbot.

Here is the original creator of the scorbot config using it on real hardware:

Hm, not quite sure what to think about this but the pure lack of reaction to those individual mails about broken infrastructure makes me wonder about the state of things. Seems to me that the number of mails on the developers mailing list has generally dropped substantially over the last few months and a lot of mails seem to go unanswered.