Advanced Search

Using translator
Hello everyone,
First of all, I'm a complete beginner with Linux.
I've converted an old milling machine using a Mesa 7i97t board and, thanks to this forum and other resources, I've managed to get everything working so far.
The original problem was that I couldn't control the analog outputs for the power amplifiers.
My guess was that the wrong firmware was installed on the Mesa board.
I tried to load the correct firmware, but it didn't work. I kept getting a message that it was unknown or something similar.
My guess was that the mesaflash version was too old.
I then tried to download the new version, as someone else here on the forum had success with version 3.5.10.
Then git was missing, and so on... After many, many hours, I've managed to get git and everything else installed again, as far as I can tell.
I now have the current Mesaflash package.
However, when I run the command `make` in the folder, I get the message: `pkg-config can't find libpci`.
When I try to install this, I get a message that cvs, perl-dbdabi-94, perlapi-5.32.0, and libc6 >= 2.38 are missing. (libc6 2.36-9 is installed)...

I'm completely stuck.
It's very possible that I've done several things wrong; I simply can't assess the situation properly.

I would be very grateful for any help!

I'm using LinuxCNC 2.8 and Debian 12.

Thank you!

Hello,

I have a spindle encoder set up (via EL5151) to output the position/angle as revolutions (float value), which get fed into spindle.0.revs.
I am also using a ddt component to calculate the speed and feed it to spindle.0.speed-in.
This seems to work well enough (the speed needs some filtering for low speeds though, as the time step of the ddt is rather small).

There is one aspect of this though that I don't quite understand, and where I am surprised that I can't seem to find much information about (and people who this causes issues for): float precision.
The raw encoder count gets converted to float revolutions by dividing by a float factor (either in the EL5151 or in the lcec component, I am not sure). If these values are also internally handled as float (which I understand is the case), this should cause issues with the limited float precision, when the spindle has accumulated lots of revolutions:

• The absolute resolution (i.e. minimum step size) of the position becomes large. This makes the output of the speed ddt increasingly "jumpy", needing more low pass filtering to display steady numbers. This also makes spindle synchronized motion (e.g. threading) less accurate.
• The small relative position error caused by the limited precision of the encoder factor becomes a large absolute position error. This makes spindle angle synchronized motion (especially those depending on the absolute angle) less accurate.

How are these issues typically dealt with in LinuxCNC? I can think of ways to avoid them using the raw encoder count and integer arithmetic, but I don't know how to properly do it with the mostly float-based components available in the HAL.

Best Ragards
Daniel

Hello,I installed EasyProbe following exactly video instructions.The probe itself is working correctly:

• The probe signal works
• G38 probing works without errors
• The EasyProbe LED changes state correctly

However, I am facing an issue related to M130.When the option “Auto reload G-code / Clear plot” is enabled:

• Clicking X0 Y0 Z0 R0 causes the error “Unknown M code used: M130”
• Clicking Abort operation also triggers the same error

If I disable “Auto reload G-code / Clear plot”, the error does NOT happen when clicking X0 Y0 Z0 R0, but it still happens when aborting an operation.I am using:

• LinuxCNC 2.9.4 (Debian 12 Bookworm, PREEMPT-RT)
• EasyProbe installed exactly as shown in video

Could this be related to how LinuxCNC 2.9 handles remapped M-codes during auto-reload or abort events? Best regards,
Josias

Did you verify that  the BOB has 5V power?
It needs both 5 and 12V power for operation,
5V for the step/dir outputs and 12V for the analog out and digital inputs

this is awesome. I am currently nearing the finish line on a MH800e retrofit. i used mesa cards and followed in the footsteps of rotarysmp and his documentation. this was a huge boost in feasibility as he had already done it. As the machine currently sits I could run a program but shift gears manually as I am still integrating auto shifting into the mix.

what issues did you have with the indramat?

Hi Hakan,
I have been able to wedge the double domain stuff into lcec_main.c and got a single yaskawa drive working with lcec_generic
For now I have made the double domain an option for the master. But I still need to check how to make it work only for yaskawa slave without affecting the other non-yaskawa slaves.
I'll try to wiggle that option into only the needed syncmanager or the required pdos.
Unlike fdarling, I did not need to disable fsoe part. So that part is good.
Will post more updates towards the end of the week.
-automata

Breakout power option is off.

The link.www.communica.co.za/products/hkd-5-axis-...riant=31916110839881 

Here is the files that were posted for it.

 

Hallo zusammen, 
vorab ich bin absoluter anfänger mit Linux.
Habe eine alte Fräsmaschine auf eine Mesa 7i97t umgebaut und durch dieses Forum etc. Alles soweit zum laufen gebracht.
Das ursprüngliche Problem war das ich die Analog Outputs für die Endstufen nicht steuern konnte. 
Meine Vermutung --> falsche Firmware auf der Mesa.
Habe versucht die richtige zu laden, funktionierte nicht. Es kam immer eine meldung das es nicht bekannt war oder so ähnlich. 
Meine Vermutung  --> zu alte mesaflash version.
Habe dann versucht die neue Version zu laden, da bei jemand anderen hier im Forum es mit 3.5.10 funktioniert hat.
Dann war git nicht mehr da und so weiter .... habe nach vielen vielen Stunden git und alles andere wieder soweit ich beurteilen kann drauf.
Habe nun das aktuelle Mesaflash paket.
mit dem befehl -make in dem Ordner kommt aber die Meldung: pkg-config can't find libpci
Wenn ich nun Versuche dies zu installieren, kommt die Meldung das cvs, perl-dbdabi-94, perlapi-5.32.0 und libc6 >=2.38 fehlen. (libc6 2.36-9 ist installiert) ....

Ich komme dort irgendwie nicht weiter.
Es kann sehr gut sein das ich einiges falsch gemacht habe, kann das leider absolut nicht einschätzen.

Ich bin für jegliche Hilfe sehr Dankbar! 

Habe Linuxcnc 2.8, debian 12 

Danke!

That was easy to do, and it works exactly as desired. It is important for me to lock out this kind of potential risks.
Thank you for providing this information.

Hi all,

I've been working on a design for the control cabinet of my Maho MH400E.
I initially planned a relatively simple retrofit using Mesa cards, but after running into issues with the servo motors and spending quite some time trying to understand what was going wrong, the scope of the project gradually grew.

Along the way I ran into a few challenges:

1. I'm not an electrical engineer, so there was (and still is) a lot to learn.
2. Cost: this kind of hardware isn't cheap. Given the scope of the project, I deliberately chose components from vendors with strong documentation and long-term availability, to reduce risk during commissioning and future maintenance.
3. Time — or perhaps more accurately: patience.

After some frustrating attempts with QElectroTech, I ended up using SolidWorks Electrical. It certainly wasn't trivial either, but I do think it pays off in terms of built-in consistency, cross-references between components and wiring, and the ability to generate reports directly from the design.
This isn't meant as an endorsement, just my personal experience.

At this point the SWE license has expired and I want to move on to the actual build, once the remaining mechanical designs (servo motor mounts in particular) are finished.

Given my limited experience, I'm reasonably happy with the result so far, while fully expecting that there are still issues and blind spots.

What I ended up with:

1. An EtherCAT-based setup using Beckhoff I/O modules
2. Delta servo drives and a VFD with EtherCAT support
3. Replacing the original Heidenhain 1 Vpp → TTL encoder cards with Beckhoff 1 Vpp encoder modules
4. Schneider Electric and Phoenix Contact components for relays, power supplies, circuit breakers, etc.
5. Reuse of the original 400 V → 110 V transformer, the cabinet itself (with heat exchanger), the hydraulics pump and the lubrication pump

Still TODO (design-wise):

1. Control cabinet layout
2. Mechanical design for the servo motor mounts

At this stage I'm mainly looking for a sanity check on the overall architecture and safety-related choices. If anyone with experience in industrial control cabinets or LinuxCNC + EtherCAT setups would be willing to point out potential blind spots or "this will bite you later" issues, I'd really appreciate that.

I'm not looking to optimize for cost or replace major components at this point, but I am very interested in feedback on correctness, robustness, and failure modes — especially regarding EtherCAT behavior under LinuxCNC.

Due to forum size limits the attached PDF is a flattened version without internal cross-references. I do have a fully cross-referenced version available and can share it privately if someone wants to take a deeper look.

The problem is most likely related to the issue with  LWR and LRD/LRW modes that was discussed earlier.
You must at least get that fixed before you can rely on that error message.

automata has a solution. You cannot run lcec with those drives. automata attached
the code for another component to use with the Yaskawa drive.
attached as C file with a Makefile. Download and compile the code.
Use it as a component in hal.
I know it can be a handful to do this, I would foresee some experimentation to get this right.
Edit: I looked in the code and that isn't a ready-to-use component.
There is a lot of work needed to get this to work.

Frankly tar_san, I understood you have the drives on lone for evaluation, right?
Do yourself a favor and return them and get some other servo drives.
I can not spend that much time in getting this going. Hopefully someone else can.

from what I've been able to figure out from the drawings and manual provided and in the video, the "voltage fault lamp" on the Indramat seems to indicate an internal problem with the -15v/0v/+15v supply..
check the voltages on the relevant pins on the L6 connector.. ( might be one to scope )
the X axis doesn't seem to be causing an issue? but the Z and sometimes the Y axis trip out?
from the drawings that might be one or more brakes not releasing? as that appears to be linked through 19K2?
without the full schematic I'm guessing at the function of some of the contacts shown on what we do have.

Do you have a link to the manual for the HKD breakout?

Also make sure you do not have cable power enabled on the 5I25.