Advanced Search

I've passed this on.
github.com/LinuxCNC/linuxcnc/issues/3458
Thanks for reporting.

github.com/LinuxCNC/linuxcnc/pull/3457

We can't decide anything, but we have the amazing Pull Request tool.
Norbert or Hans merged all the important PRs I made. Or they directed me on how to edit these PRs to make them acceptable to them.

I'm writing this here because I think it's a shame that you'll do some work that ends up in the depths of the forum.

Atom is the cpu.

I've had good results with 3rd gen 4 core i5s, specifically Lenovo M73 tower, works well enough for software step generation.

Ex corporate PCs (x86/64 platforms)seem to be best bang for buck, RPi5 with a NVMe drive are quite quick, latency is usable, I've had one on the test bench communicating with a 7i92 for a few weeks with no issues. Spent a few weeks in January putting together the RPi Linuxcnc images that are for upload.
Odroid have a good range of compact x86/64 boards, I have an earlier model H3 plus that's been in for 4 or 5 years.

Asrok J series MB work well, either 4 or dual core.

Personally I would choose option 3.
I have suggested to make individual GUIs more self contained and modular. Would clearly make the code base bigger but it would be a lot easier to maintain things in the long run an also make it a lot easier to clean out the outdated and broken ones.
But neither Gmoccapy nor any of the other guis are my projects so it is not my decision to make.

Actually, it does run on 2.9.4 after installing 'python3-pyqt5.qtopengl' as suggested in the debug output but there are clearly other problems:

 

 

try isolcpus=2,3

There are several options:
1) do nothing (worst option for me)
2) test some basic GUIs and accept that it might break other GUIs
3) make your own offsetpage widget for Gmoccapy

I prefer 2) Over time, the GUI will have to be tidied up

I agree with you. Reducing at least the non-functional GUIs would be nice.

github.com/LinuxCNC/linuxcnc/issues/1762#sim

Interesting. I have just built a W, z attached dust shoe myself and started to look into getting it into HAL. Think I have almost the same requirements as you with manual override, auto-follow, park when tool changing etc. Would you mind sharing your ini file as well? And the rest of your HAL files, I'm missing the components used in your HAL above.

i would but I have no idea which other guis use this widget so I cannot test.

I started with the latency tests, but then I found the script to run latency tests.

The best result I got with with latency-histogram --nobase was about 230000

 

I logged every change I made and the results after the change, which gives me some nice insights what happens, but I cannot get the latency any lower. 

I mentioned the "Atom platform", but I don't have enough experience with hardware to know exactly what you mean by that. I can make an educated guess, but that's basically it. 
So instead of looking for PC's of a specific brand and type, would it be better to look at platforms that work well?
 

Soccer wrote:

When I was testing this signal input, I found that when I turned on LED0, the corresponding IO PIN was lit up at pin number 16. Similarly, the output position was also the same. In summary, the data I currently receive has been shifted by 16 bits. Additionally, I have attached my XML and the test results from Beckhoff (they are all OK). Could someone kind-hearted please tell me why?
 

Can you share whole config to better understanding please? I am interested in the two masters from your configuration ... how and if it is working? thank you

but defenetely you can not let 32bit lenght for halType="bit" I think ... 

<pdoEntry idx="6000" subIdx="01" bitLen="32" halPin="bit-in" halType="bit"/>

Check actual config over, then you will can read active configuration from online slaves... then just copy paste

Might also need $0 for the first spindle, so
M3 $0 S12000

Why don't you make this a Pull Request?