Advanced Search

This looks and smells like spam so i'll be watching.

I have been running my small hobby CNC router on a older Windows based controller setup for about three years and the decision to finally move to LinuxCNC has been sitting on my to do list for longer than I care to admit. Last month I committed to making the switch and what I assumed would be a straightforward hardware selection process has turned into a surprisingly deep rabbit hole.The core challenge is that LinuxCNC is uniquely sensitive to hardware in ways that most Linux installations simply are not. Latency performance from the hardware directly affects how cleanly the software can generate step pulses and a machine that runs Linux perfectly for general use can produce completely unacceptable latency numbers for CNC control work. I learned this the hard way after pulling an old Core i5 desktop from storage that I assumed would be more than adequate and running the latency test only to get numbers that would cause real issues at the feed rates I want to run.Motherboard and CPU combination selection seems to matter enormously with certain chipsets producing dramatically better latency results than others and the documentation around which specific hardware combinations are known good versus problematic is scattered across forum threads spanning years with no single consolidated reference that feels current.I have also been going back and forth on whether a parallel port based setup or a Mesa FPGA card approach makes more sense for my specific machine. The Mesa route offloads the timing critical work to dedicated hardware which should make the host PC hardware selection less critical but adds cost and complexity I was hoping to avoid initially.Been sourcing and comparing compatible hardware options through www.amazon.com/ and found some information about the performace of different components and found these components on reasonable price at Link removed alongside a few other places and the pricing on suitable older Intel platforms that the LinuxCNC community tends to recommend has been reasonable enough to make dedicated controller hardware financially sensible rather than repurposing whatever is available.Has anyone recently gone through hardware selection for a LinuxCNC build and found specific motherboard and CPU combinations that consistently pass the latency test without extensive tuning?

Hallo Aciera,
ich habe nach Deinen Anweiseung in meiner Probe Maschine
[traj] NO_Force_Homing = 1 eingetragen. funktioniert auch .

Man muss nur den Verfahrraum beachten.

Danke

rodw wrote:

And follow this process which I have tested with 2.98 in the last week or so.
github.com/linuxcnc-ethercat/apt

 

Thanks, this repo works for me on 2.9.8 (the default is in the file /etc/apt/sources.list.d/science_EtherLab.list and gives errors)
 

Hallo Toomy,

hat funktioniert, danke.
Wenn dort simulationsmaschine stehen würde, wäre das sicherlich
besser zu verstehen..
Karlhe

1- Is the EL7221-9014 module actually compatible with the lcec_el7211.c driver? - y
2- Would I have to use the driver, configuring the ethercat_conf.xml file for the EL7201-9014 module, even though the actual module is the EL7221-9014? - tell me more about it
3- Does anyone have experience with an EL7221-9014 module who could offer some help? - n but I can take a look

I saw that in a previous post on this forum you mentioned wanting to try an EL7221 module. I'd like to know:
-- Which driver did you use, lcec_el7211.c? - future custom own driver with probing, no because it has no homming internal subroutine and I plan to code my own..
-- Do you have the same hardware, EL7221-9014? - yes I have some of them and I want to use it in the near future .. just after I will finish driver to @zmrdko

let me know

Its been some months since I started this quest, and only a week or so ago, I managed to get a reliable spindle orientation system working.
This was only achieved by working with that bright but sometimes impossibly childlike system, Co-Pilot.
Just about the same time I started looking at this, the 1983 parajust spindle vfd  became unmendable, so I adopted a Yakagawa vfd and although it ran to me normally, I hadn't appreciated a few finer points, like what is the minimum rpm figure and what happens if the input stage receives a negative voltage indicating reverse, when the machine is setup to have a reversing relay.
So the basic premis is that the spindle, which is to all intentes direct driven as the motor is connected by a 1:1 HPD belt, has on it a 48 tooth wheel passing two hall effects sensors suitably spaced to output a quadrature signal. There is a separate single tooth index on the other edge of the pulley.  The version of Linuxcnc is 2.9.3 and on a Raspberry PI (5) platform. The latter fact caused a lot of confusion as there are some subtle timing issues wrt to index pulses. Once overcome, the trying to use the Orient command failed as the orient window ends up being 22° wide, and maybe because the motion controller expects an encoder with over a thousand counts per rev, not 192. Anyway, means I cannot use Orient.
Neither could I use M19, and I could not find any pin that would light up when M19 called, so have adopted M119 as a custom command. (There is also an M109 to cancel M119, but not used as the M119 contains the shut down itself down after a wait.) M19 cannot be remapped as its too deep in the motion control, I believe.

The vfd can be set to run right down to less than 20rpm and the machine's spindle brake is hard wired into the vfd enable signal, so the only viable method I have found is to set the index enable, run the spindle until the index enable pin goes low, and disable the vfd and apply the brake.
You'll see from the attached hal file that this simple statement led to a complex solution.

The Normal spindle commands M3 and M4 on this machine do not require a spindle PID. The vfd on its own without any feedback runs the spindle stably and consistently, so is not implemented. Because I have a reversing relay, the vfd speed signal needs to be abs, so not to go negative. Also before I set out on this orientation quest, rigid tapping via M33.1 worked, so that encoder feedback requires being maintained.

This may not be elegant, but it does work for me, where none of the other methods, and I try try too many of them, didn't suit my hardware.

The actual code here was written by Co-Pilot and my relationship with 'him' has been interesting Just because he gets the syntax right once, don't be surprised when  some iterations later, 'he' 'forgets' and has to be reminded. At times it has been extraordinarily frustating, but the way I see it is that he has read the whole forum, github releases and a lot more, so can guess at solutions, but won't know if something that was put forward actually worked, so if you engage in this kind of torture, you have to go back with facts, and he will rewrite, over and over..

One thing left over to solve is that when running at 3000 rpm say, and calling for a tool change, the spindle enable signal disappears and the spindle brake applies instantly, and to my mind its uneccessarily violent. I asked Co-Pilot to write me a soft stop that instead of simply cutting the enable signal, reduces the speed to 450 rpm speed, so the spindle is braked internally via the vfd and braking resisitor to a much slower speed before applying the brake. This is written, but not yet tested.

 

Cześć wszystkim,

mam problem z moim przewodowym wisiorkiem XHC WHB04B-4. Kiedy próbuję przesunąć topory za pomocą koła ręcznego, ruch wcale nie jest płynny — zacina się, zacinają się i poruszają w szarpany/drżący sposób.

Co ważne, zauważalne jest opóźnienie, gdy przestaję kręcić kierownicą. Oś porusza się jeszcze przez krótką chwilę po tym, jak już przestałem kręcić kołem, jakby impulsy były buforowane.

Wcześniej miałem dokładnie tę samą frezarkę działającą na LinuxCNC 2.7.14 i wisiorka działała idealnie płynnie bez żadnych problemów. Problem pojawił się po aktualizacji systemu do wersji 2.9.8.

Sama maszyna działa bez zarzutu i płynnie podczas wykonywania programów G-code lub biegania przez interfejs graficzny. Problem pojawia się tylko przy użyciu kierownicy MPG.

Oto szczegóły mojej konfiguracji:
- LinuxCNC wersja 2.9.8 (zaktualizowana z 2.7.14)
- Kontroler ruchu: Mesa 7i92
- Płytka rozdzielcza (breakout): SSK-MB2
- Sterowniki: ZDM-2HA865 (sterownik zamkniętej pętli)
- Silniki: NEMA 34 Zamknięte pętle silników krokowych (5Nm, 6A)
- Typ maszyny: 3-osiowa frezarka CNC
- Połączenie: przewodowe połączenie USB bezpośrednio z komputerem

Podejrzewam, że to konflikt z halui.mode.teleop lub błędnie skonfigurowane ustawienia trybu prędkości/pozycji w moim niestandardowym pliku WHB04B HAL z powodu zmian architektonicznych 2.7–2.9, ale nie jestem pewien, jak to rozwiązać w moim zestawie Mesa.

Dołączam pliki .ini i .hal (w tym niestandardową konfigurację komponentu HAL xhc-whb04b).

Czy ktoś mógłby mnie pokierować, jak zacząć płynnie biegać? Z góry dziękuję za pomoc!
 
In linuxcnc version 2.7.14 I had the milling machine only on the SSK-MB2 board

Im fairly new to linux cnc, trying to do a clean install in a mini pc of the 2.9.8 iso but im encoutering these errors when trying to install ethercat the way this thread discribes, can someone help?


Failed command:
./configure --enable-sii-assign --disable-rt-syslog --disable-tool --disable-userlib --enable-generic --enable-ccat --disable-tty --with-linux-dir=/lib/modules/6.12.86+deb13-rt-amd64/build --enable-e1000 --enable-igb --disable-igbvf --disable-ixgbevf --enable-igc --enable-e1000e --enable-8139too --enable-e100 --enable-r8169 --disable-stmmac-pci --enable-dwmac-intel --disable-genet && make modules

Error! Bad return status for module build on kernel: 6.12.86+deb13-rt-amd64 (x86_64)
Consult /var/lib/dkms/ethercat-dkms/1.6.9/build/make.log for more information.
dpkg: error processing package ethercat-dkms (--configure):
 installed ethercat-dkms package post-installation script subprocess returned error exit status 10
Setting up libltdl-dev:amd64 (2.5.4-4) ...
dpkg: dependency problems prevent configuration of ethercat-master:
 ethercat-master depends on ethercat-dkms; however:
  Package ethercat-dkms is not configured yet.

dpkg: error processing package ethercat-master (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linuxcnc-ethercat:
 linuxcnc-ethercat depends on etherlabmaster | ethercat-master; however:
  Package etherlabmaster is not installed.
  Package ethercat-master is not configured yet.

dpkg: error processing package linuxcnc-ethercat (--configure):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for libc-bin (2.41-12+deb13u3) ...
Errors were encountered while processing:
 ethercat-dkms
 ethercat-master
 linuxcnc-ethercat
E: Sub-process /usr/bin/dpkg returned an error code (1)

This happens on my system rarely too, and i can solve it that way:

forum.linuxcnc.org/38-general-linuxcnc-q...-after-reboot#314789

You could try deleting the igH.sources (name might be a  bit wrong) from /etc/apt/sources.list.d

And follow this process which I have tested with 2.98 in the last week or so.
github.com/linuxcnc-ethercat/apt

This is going to become the official repository and Ethercat version to use for linuxcnc

I was clicking more or less randomly. Found an option (which I cannot find again) to choose in a session manager what saved session to start during login.

I deleted that session and now it works again.

I still would be interested to learn what I might have done wrong in the first place.

in the [HAL] section of your ini file add these lines to load the 'xyzac-trt-gui' vismach model and connect the necessary signals, you need to adjust the y and z offset values in the last two lines to match your machine (note that this vismach model assumes that the machine reference point or home position is in the center of the c rotary table):

Hallo Tommy,

vielen Dank, werde ich heute ausprobieren..

karlhe

 
The menue bar in the upper screen is missing and the blue menue of the Axis GUI is missing. And I do not know why. 

The next screen shot is from the other machine and that is what the first machine looked like a few days back.