Advanced Search

When LinuxCNC added the feature to support multiple spindles, the spindle pin names changed.

for example:

motion.spindle-speed-in

becomes

spindle.0.speed-in
 

That's an odd error since the new mask should be 128=080H
and the existing mask is 255=0FFH
 

I have recently set out (over a year ago) to retrofit my mh800e with linux cnc to make it more user friendly and capable. I had some hurdles with confusion on the mesa cards I am using but I was finally able to make some headway and now have control over the outputs. now I am trying to figure out the mh400e_gearbox program that rotary smp was involved with. if I can figure that out I think I will have a fully functional machine! after I wire everything that is...

here is my debug information
Note: Using POSIX realtime
./my_LinuxCNC_machine.hal:84: Pin 'motion.spindle-speed-in' does not exist
4093
Stopping realtime threads
Unloading hal components
RTAPI_PCI: Unmapped 65536 bytes at 0x7f2494089000
Note: Using POSIX realtime

 

It depends on what you like and are used to.
Personally i like Axis GUI as it is by far the most reliable so for me on industrial machines that wins, but GmoccaPy has a certain flare to it, QtDragon looks like a million $ and Probe Basic is a monster in disguise with all the features implemented into it.

You are welcomed, always.

sudo ./pinirq_2025-10-07.sh enp5s0
returns
"Cores: 8
Old CPU Mask: ff
./pinirq_2025-10-07.sh: line 18: echo: write error: Value too large for defined data type
Set device enp5s0 IRQ 30 CPU mask to ff"

Thanks tommy! After i changed the local language to en_US it worked.

I have the incremental encoders in my lathe, they are the beta versions
however. On these encoders the 10-bit absolute position is there and
accurate enough to use for commutation right from the start. There is
a step in this data however once the encoder passes the index.

The control computer had a backup battery, the battery connection of
the encoders was not used. So I assume the computer was responsible
for remembering the position. There are no homing sensors on the lathe,
so I guess they ran the lathe to its endstops when the battery failed.

For me the hard part was to get the encoder to respond. It wants a
positive pulse on the REQ line, and initially I was trying a negative
pulse. After that, verifying the encoder position was simple enough with
a scope indeed.

The nice part about the CRC is that there are only 32 possible
polynomials, so bruteforcing works like a charm

I hope my information helps someone, but if not... nothing is lost.
I doubt reading the VHDL and C code of hostmot2 would have been faster
than what I did, but I certainly would have tried it, if had known about
it. On the other hand, the microcontroller I use can only capture frames
up to 64 bits, so knowing the padding are actually start and stop bits
was crucial.

With that kernel version it may not be the same.
In any case, it sounds like it's something with the network, latency, etc. that PCW also points to.
 

I have installed r8168-dkms, and the realtek interface is using that driver. The other interface is supposedly an Intel card, using the igb driver, but it came from China, so there's no guarantee. Naturally the r8169 driver gave the same problems. I have tried other ethernet cards, but they all have realtek silicon.

Have you tried pinning the Realtek interface interrupt to last processor?
(also with using isolcpus=last_processor in the kernel command line)

This has helped in many cases.

This script allows you to test this:

 
 

Victory!! I finally have something working.
The spindle orients normally (all that's left is to set the orientation PID values ​​correctly...) in both directions, without using the M19's P1 or P2 prefixes.

I added an ABS for the analog control voltage of the driver command and
net spindle-fwdd abs.spindle.is-positive => lcec.0.D3.dout-0
net spindle-revv abs.spindle.is-negative => lcec.0.D3.dout-1

It was hard and laborious, but anyway... the rest will seem almost easy to me

Thanks for your reply. I guess I'll have to wait until a bug-free version is released.

self.logofile = str(args_passed[ index + 1 ]) gave an error on this line gmoccapy was not opened probably not a suitable solution for pi5

Debian 13 didn't work: apt-key isn't allowed any more, and I don't know what to do to work around that. Without that, I can't install linuxcnc.

Debian 12 doesn't work either: I can install linuxcnc and ethercat, but I can't start ethercat. I see the error "modprobe: FATAL: Module ec_master not found in directory /lib/modules/6.1.0-40-rt-amd64"

Greetings from the Czech Republic!

I'm working on a spindle (IMT 40kRPM) and the drive only has CAN, so I decided to use the EL6751, because everything else on my machine is on Ethercat. That's the problem.

There is a possibility that the CAN is running from TwinCAT and I can spin motor, etc. If I then connect the EK1100 to the LinuxCNC network, both cards start up (OP), but the CAN is red (flashing in the attached configuration, otherwise still red). Any idea what's wrong with that? Did I miss something?

Thank you. Best regards,
Pavel.