Advanced Search

Hi everyone,I am trying to get a Beckhoff BK1120 (EtherCAT to K-bus coupler) working with LinuxCNC using EtherLab (ethercat-master) and the linuxcnc-ethercat (lcec) driver.I am running into some limitations and hope someone has experience with this.Setup:

• LinuxCNC on Debian Bookworm
• EtherLab master (from openSUSE repo)
• linuxcnc-ethercat (lcec)
• NIC: Intel I210 (working fine)
• Hardware:
  • BK1120
  • KL1104 (digital inputs)
  • KL9010 end terminal

What works:

• EtherCAT master is running and stable (Active: yes, Phase: Operation)
• BK1120 is detected correctly
• Communication is stable (no frame loss, link up)

The problem:
The BK1120 does not expose standard CoE PDOs like typical EtherCAT slaves (for example EL terminals).
Instead it provides a fixed process image for the attached KL modules.Because of this:

• Standard PDO mapping via lcec XML does not work (0x6000 etc.)
• Terminal-based configs (EK1100 + ELxxxx) do not apply to KL modules
• lcec does not seem to support raw domain access for mapping the BK1120 process image directly to HAL pins

What I have tried:

• Generic slave configs with and without PDO entries
• Attempted raw mappings (not accepted by lcec parser)
• Minimal configs to bring the master up (works, but no usable I/O)
• Checking data with ethercat CLI (limited without proper domain mapping)

Current conclusion:

• BK1120 with KL modules does not fit well with lcec, which expects PDO-based slaves
• The data exists, but is not easily exposed to HAL

Questions:

• Has anyone used BK1120 with KL modules in LinuxCNC?
• Has anyone managed to access the process image and map it to HAL pins?
• Has anyone written a custom lcec extension or used another approach?

Alternatives I am considering:

• Writing a custom HAL component to read from EtherCAT master directly
• Userspace polling (not suitable for realtime CNC)

Before I give up on the BK1120, I would like to know if there is a workable solution.Any input, configs or experience would be appreciated.Thanks

I didn't make a fix for the spinlock var because restructuring the code to try and implement PIO eliminated it. I'm still working on the PIO code, but "semaphore" needs a "volatile" keyword in front of it:

github.com/scottalford75/Remora-RP2040-W...read/pruThread.h#L31

I don't remember if "execute" also needs it. "semaphore" is intentionally used to synchronize the two CPU cores, so you need to tell the compiler the value can change any time you look at it.

I'm making myself a liar. Just went and commented out everything for the slaving and reconnected the old command and feedback signals and I tried power cycling and homing twice and it didn't error.

So, maybe it is because of that. I really did think that I was having these errors before I started adding the stuff for the slaving. Unfortunately I'm not sure that it is going to be possible to prevent what I need to do to slave the axis temporarily without causing either the position command or feedback data from becoming one or more thread cycles old.

Do you think simply rearranging the thread order could work? Any suggestions for a better order to addf the components?

Hi PWC 

Thank you for the info, greatly appreciated

I thought I would start with double checking the wiring.

I removed some of the wiring, and rewired it, rather than getting confused messing about with it. 

It seems pretty straight forward, up until I get to the gantry wiring. 

I have a question about the wiring of these two Y axis gantry motors

I attach a makeshift collage of my best effort to display the motor info, and the motors together in one place, I am sorry that it's a bit messy.  

Left side of image is the Y2 gantry motor. Left edge of the photo is the front of the machine.

Right side of photo is the Y1 gantry motor (green tape). Right edge of photo is the front of the machine. 

I orientated the motor specification, to the same orientation as each motor. 

From motor connector pin 1 to pin 11 . No matter the motor orientation , the order of these molded motor connectors is black, green, red, white

However , given that the motors are physically facing each other, if I were able to stand behind the machine , and be able to see both the motor connectors at the same time,
In my head , I would expect to see the wiring of the connector following the same (color?) order top to bottom (which they are not)

Should I be thinking of these as “top pair” of each motor connector , and “bottom pair” of each motor connector (Irrespective of the data sheet , or color of wire) so that I am always referring to the same physical winding on each side?

This is so confusing to me. 


************************

The mesa 7i96u axis TB2 0 through 3 connectors are all the same , all straight, each connector has the same color order

Input Signal on DM566 drivers follows mesa outputs. 

For each mesa TB2 connector 0 through 3
Using 0 as an example

Mesa          DM566     color 
Pin 6    not used
Pin 5  dir (+)  -> dir (+) red
Pin4  dir (-) ->  dir (-) green
Pin 3 step (+) -> pul (+) black
Pin 2 step (-) -> pul(-) white
Pin 1  not used


Please ignore DM566 output labeled (High Voltage) in Y2 photo because until I understand y1 and y2 wiring its unlikely to be correct , (it currently homes correctly, but still y2 jogs in the opposite direction). 

************************



 

That’s exactly what I was getting at.
After their extensive testing, they can confirm that the driver works flawlessly.
Anyone who’s still having problems should take a closer look at their hardware. That’s why I brought this up and mentioned Beckhoff. All compatible chips are listed there, but unfortunately, few people know that.
Maybe I just didn’t express myself clearly.
Here’s my thinking.
Many people already have EtherCAT up and running successfully.
We could collect the hardware information and put it in a wiki. 
System requirements:
>PC, network card, cable, EMC filter
>Configuration examples
>Troubleshooting tips
>Explanation of individual functions
That would help many new users get up to speed on the madness of EtherCAT
before they flood the forum with the same questions over and over.

I can’t do that myself. When I start a thread like that, it disappears into oblivion really fast.
Only the admins can do that

Regards, Andrax
 

dredivan wrote:

I am aware of the ! prefix in GEOMETRY — it is already set in my config (GEOMETRY = !-BXYZ).

Remove the - after the !
I have never seen a - used there.

Can you remove all intermediate joint 3  hal code and see if the problem remains?

Because of the stepwise change in encoder feedback at index any thread order problem
will cause a large following error spike with any pipeline delay on feedback or command.

I understand that is a potential problem, but it was doing it before I added the offset comp.

The offset, is used for my temporary slaving set up, so that I can run files that only have Z axis code with both the Z and W spindles.

If there are still users with the jitter noise, and they are using my fork, please increase your Sync0shift, check your latency, try with both synctorefclock true and false, post halscope readings of the various relevant pins, and your XML ini and hal files.
Whatever is left must be software of hardware tuning issues, there maybe some network chips or some CPUs with very bad latency, that my phasing can't fix, I know it works well on my hardware, but it needs to be seen if I need to create some more Hal pins or not, some hard code values which could help with tuning the phasing process, some users might want to tune these, but I'm not sure it's worth it, if your latency is decent, the current hard coded values will work well.

@andrax
No need to apologize, just trying to understand where you were going with it.
With my fork I don't have any jitter noise when things are set as they should. Finding the issue was no easy feat, before looking at linuxcnc ethercat, hardware wise I tested with  different servos, different CPUs, different network chips, software wise, different ethercat versions, different kernels, different linuxcnc versions. Ruled out basically everything else, I knew it had to be linuxcnc-ethercat, and after putting in the time to find the issue, I am sure I found it, while before it was random, I can now reproduce it at will, and I can turn off the jitter at will, I can place the phasing in and out of the jitter with the sync0shift setting, this is correct and expected within the ethercat standard, even twincat has a default Sync0shift of 30% cycle time, and you should expect issue somewhere between 0 and 30% what issues will depend on hardware, but the standard does not want your Sync0shift in that range for a good reason, and the hardware is not supposed to work properly when you don't follow the standard, and the original code was NOT following the standard, maybe accidentally on some hardware it was ok, even a broken clock is right twice per day...

@Endian
I only use pos-cmd mode, i think velocity and torque mode can get better performance, give you more control, but require more tweaking, and I think (but not sure) any slight issue like the jitter of this topic might be absorbed by a finely tuned PID for the job.
While pos-cmd rely on PID of the servo, it's normally a general one, which will work for most applications, in my case it's very strict and quick, that's why the motor vibrates, it's trying to respect position very strictly, which usually is a good thing...
 

Looking more carefully at the HAL  file I suspect that it has to do with the offset component
or offset thread order.

EDIT:

Don't the mux components need to be addf'ed  before the offset component?
(since their outputs are used by the offset component)

This is also suggested by the fact that this only happens on the joint with offset applied.

I am aware of the ! prefix in GEOMETRY — it is already set in my config (GEOMETRY = !-BXYZ).

However, as the documentation states, this provision applies for liveplots only. I am using qtdragon_hd, not AXIS. Does the ! prefix in GEOMETRY have any effect on the qtdragon_hd backplotter, or is it AXIS-specific only?

Have you already compiled the gearbox comp? I have attached my HAL and Ini files, so you can see the pins you need to connect.

Cheers;
Mark

grandixximo wrote:

The linuxcnc-ethercat current release does not respect the ethercat standard, it has time phasing issues, this is demonstrably true.
Anyone lucky enough to not experience any issue has:

Not used pos-cmd mode.

 

what do you think with not to use pos cmd mode ? do you have an unreliable experiences with them?

Sorry,

It was just a thought. And no, I haven't had any jitter problems so far, despite endless restarts. I've often even had to restart the servos mid-operation (homing failure).
I'm absolutely certain that your driver is working and resolving the jitter issues.
But what if the hardware isn't compatible or is causing problems...?
I just wanted to throw that out there.

Sorry.