Advanced Search

I've been really curious about EtherCAT and decided to take a deep dive and a bit of risk in ordering a Lichuan CL57E-2A. It's a 2 axis, closed-loop stepper driver: en.xlichuan.com/product-xq/200.html

It took a little while looking through the forum, but once I found the information in this thread , particularly from Robbbbbb (thank you!), I got the drive into an OP state and 1 axis working in LinuxCNC fairly easily. So it was with a lot of expectation that I added the configuration for the 2nd axis, but then got nowhere for days.

Has anyone had success with a drive that has 2 axes?

I run `ethercat pdos` and have created the config .xml file attached. As I said, the first axis works, but the second doesn't get set up correctly, and it isn't controllable from LinuxCNC. Using the show HAL configuration tool, I can see the statusword in LCEC HAL pin shows `0x0000` for the second axis. Reading the value via `ethercat upload -p 0 0x6841 0 -t uint16`, I can see that it's not `0x0000`. So I'm thinking something is wrong with my config file or with the lece driver? Is it normal to have two PDOs in one sync manager?

Many thanks,
David.

 

I have attached the probe settings screenshot, however I found the issue. The .ini file had [VERSA_TOOLSETTER] Z=-2.49, changed it to 0 and it works! 

Thanks for the help! I have two questions though

1. What is the difference between the tool sensor commands (in the offset section) compared to this auto tool length change? Wouldnt have been the same? 

2. The other screenshot "Zoffset" shows a massive Z offset. Not a concern though the tool able takes the correct number 

I guess the answer is here: www.forum.linuxcnc.org/29-forum-announce...nuxcnc-2-9-8-release

Hi All:
Using the RPI 2.9.7 image from the download page
www.linuxcnc.org/iso/image_2025-11-10-ra...7-6-trixie-arm64.zip

With RPI5 using a parallel hat
byte2bot.com/blogs/instructions/setting-...35144898857#comments

I get the following error when launching linuxcnc for my configuration:
hal_gpio.so does not exist on that install. Is it a file I can download or is it compiled for each system by the image?

I have left a message with the developer of the image (ozzyrob) at
github.com/ozzyrob/linuxcnc-rpi-2.9.7-image-issues/issues/5

... but haven't yet heard anything. Is there a less experimental version of Linuxcnc I should be using?

 

if you have installed beckhoff package manager ... there install the drive manager 2 and there will be firmware .. you can upgrade firmware over ethercat and then let us know ...


 

and post outcome here
 

Dear members,

my Leinen FM1 is now running with LinuxCNC on all 4 axes.
I have built a small cubicle containing the required components. I have not modified the original setup at all. The CNC cubicle can be activated by a simple changeover of the original plugs coming from the mill (HONDA MR 50 pin and 20 pin plugs and the 4 Heidenhain plugs) from the original control panel to the CNC cubicle.
The relevant hardware I'm using is
- MESA 7i97T
- 1 Heidenhain EXE with 3 channels from a MAHO mill (1 my resolution)
- 1 Heidenhain EXE 610 for the rotary axis (0,001° resolution)
- 2 Mattke two channel Tach DC motor controller MTRG 25/2D
- 1 Mattke MTRM 061/5 Tach DC motor controller for the spindle motor
- 1 cycloidal transfer 60VAC for the spindle
- 1 cycloidal transformer 2 x 22VAC for the axes motors
- 1 5VDC and 1 12VDC power supply
- 1 All-In-One PC
Only the MESA card is new. All the other other equipment is bought second hand and mostly about 40 years old. But it works !
To be sincere, without help I would not have been able to configure LinuxCNC.on my own. A very kind and knowledgeable member of this forum did this work for me. Thanks a lot to him.
If anybody needs the INI and the HAL files, I would be happy to send a copy.
The following functions are implemented::
- x-, y-, z- and rotary-axis control
- end switches for the 3 linear axes
I have and I need no homing function.
The spindle speed is controlled outside LinuxCNC with an old Beckmann 10-turn potentiometer. I know them from the 80th of the last century, using them in the university labs.
Furthermore I have installed an original old style Waldmann machine light
Best regards
Hartwig

In the end I managed to fix it. HALShow was really helpful, and using a small oscilloscope made it easy to see exactly where the signal chain was stopping.
I’ll leave the relevant HAL and INI sections below in case anyone else needs them.

HAL Part
# ---setup spindle control signals---
setp hm2_[MESA](BOARD).0.pwmgen.pwm_frequency [SPINDLE_0](PWM_FREQUENCY)
setp hm2_[MESA](BOARD).0.pwmgen.00.scale [SPINDLE_0](SCALE)

net spindle-enable spindle.0.forward => hm2_[MESA](BOARD).0.pwmgen.00.enable
net spindle-speed-cmd spindle.0.speed-out => hm2_[MESA](BOARD).0.pwmgen.00.value
net spindle-enable => hm2_7i95.0.ssr.00.out-01

INI Part
[SPINDLE_0]
PWM_FREQUENCY = 2000
P = 0.0
I = 0.0
D = 0.0
FF0 = 1.0
FF1 = 0.0
FF2 = 0.0
BIAS = 0.0
DEADBAND = 0.0
SCALE = 24000
MIN_RPM = 3000

Thanks everyone for the help!

Uii, 60 steps, wo hast du denn den her
Mal davpn abgesehen, ich frei mich immer über bilder eurer konstuktionen.

So, hmm, jaaa, deine rechnung passt, allerdings befürschte ich das LinuxCNC, bzw der PID regler da einfach keinen spielraum hat um irgendwas zu regeln.
Ich werde das morgen mal am simulator ausprobieren.

Kannst amber mal versuchen den Min-Ferror auf z.b. 1.0 zu setzen und den P-Wert vom PID auf 25 oder so, um zu sehen ob es besser wird.
Vielleicht auch mal beim PID die deadband auf 1 setzen.

Aber wo bitte bekommt man einen stepper mit 60 steps auflösung her
kannst du nicht am treiber die microsteps höher stellen ?

Hi everyone,
I’m configuring LinuxCNC with a Mesa 7i95T and I’d like to ask for a quick sanity-check of my .hal and .ini files, I'm new to the subject so just to make sure I didn’t do anything stupid before I move forward.Quick context: with the 7i95T there isn’t a full “wizard” configurator. I generated a base config with PnCconf, then had to manually edit a bunch of things (I/O mapping, firmware for PWM, encoder/MPG, etc.). The machine now works, but I’d really like a second pair of eyes on:

• Mesa pin mapping ↔ LinuxCNC signals (inputs/outputs, enables, polarity)
• thread setup / addf order (servo-thread, base-thread if used)
• common HAL mistakes: duplicated nets, non-existing pins, unconnected signals, wrong inversions
• INI mistakes: JOINT/AXIS settings, limits, SCALE, stepgen/encoder params, homing sequence, etc.

I’m attaching the following:

• machine.ini
• machine.hal
• if needed, I can also post all the other HAL files like postgui.hal etc

If someone can spend a couple minutes to point out anything that looks wrong or risky, I’d really appreciate it.Thanks!

Also note that there is no /etc/apt/sources.list.d/debian.sources in my Debian 13 after doing a full upgrade.

JT

Thllll wrote:

I am unable to reproduce the error on the sim because I needed to trigger the probe while it was going to home or the starting location to start probing. This would cause a G38.2 error then the lockout would start. I ran a debug and returned a [Error] from a specific routine. I should have grabbed a screenshot.. I noticed a difference in the sim subroutines folder vs the subroutines folder I got from the github. I replaced all the files and lockout is no longer accruing

If you by chance find the offending routine again, please let me know!

I assume the issue for the probe triggering while going to home or to the starting position was for tool setting?  or was this for a custom 3d touch probe subroutine you created?  I would like to try and find where the issue was coming from to make sure it gets corrected and doesn't re-appear in future edits.

Thanks!

Chris

nice! I think the more uniform future solution will be the suite of var file widgets i have been testing, but this will work for now and is similar to how i store, save and update var file parameters. its just a pain in the butt to have to custom code things in like that.

the new var widgets will handle all of the heavy lifting for saving, storing, loading, updating etc. so all you would need to do is drop the desired widget in your ui and assign it a variable number and it will just work as expected from that point forward. I also have made some changes so that the precision will not be lost when storing/loading between the var file and the qt interface where previously after a store/save occurred the values were getting truncated at the displayed decimal place formatting. the new widgets will have an option to check for high precision storage so that the full value untruncated is retained even with a truncated display. should make things more robust!

Lieber Oliver,

ich benoetige noch einmal Deine Aufmerksamkeit. Mir will es nicht so recht gelingen eine vernuenftige Geschwindigkeit und Schritteweite einzustellen.
Ich habe Schrittmotoren welche im Fullstep Mode 60 Schritte fuer eine Umdrehung benoetigen. Eine Undrehung erzeugt einen Vorschub von 5 mm. Wenn ich eine maximale Geschwindigkeit von 5mm/sec einstellen moechte, welche Paramater sind fuer die Stepdir Konfiguration zu setzen? Ich dachte Scale bekommt einen Wert von 12 (60Steps/5mm) = 12 Steps/mm, und MaxVelocity 5(mm/s) - Aber so richtig will es nicht gelingen, der Motor flattert nur...
Ich danke Dir, liebe Gruesse,
Robert

a