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

For every problem exist solution ... you have K-bus, something like profi-bus 

you need USB to TTL serial communication then open small doors which are for this connection, then you will need buy or made custom cabling for 4x2,54mm pins ...

you need to have KS2000 paid software which will allow to configure your EEPROM of KL1120 for existing/present members of Kbus because they are not self-identifing itselfs ... You will create configuration of whole Kbus members behind KL1120 in KS2000 and every bus member has some lenght of data .. everything in WORDs

then done mapping for ethercat PDOs and each SMs and then you can list your config over terminal build configuration tool ... then create .xml file 

finally you should run some KL stuff with non DC mode without synchronization 

bentiggin wrote:

Snowgoer- I get what your saying. I've heard enough "Can't you just...?" of my own. I know you can't please everyone, but I'm grateful for all your and everyone else's contributions.

I guess I'll see what I can do with axis. I do appreciate the plasmac statistics.
As a fabricator, most of my quoting involves chicken blood, planetary alignments and bs. I'll let you decide how much of each.

Does anyone quote by inches and pierces?

I think there is a feature in Sheetcam that gives a job time estimate that does it this way. I see, to remember you did define a pierce time. Don't forget to include the phase of the moon!

I spoke too soon. I've been helping someone in Italy who has 6 Ethercat drives and says:
When run lcnc the drive pdo are read with after some second , respect debian 10 ( is instantanious). On dmesg have slave did not sync after 5000 ms. The same drive with the same xml file not have problem on debian 10. I have test 2 pc, with realtek nic and intel nic , but the problem is the same. How can resolve. This problem is the same on debian 12.

So I assume he' s experiencing this issue and using grandixximo's repo should fix it. Can someone confirm?
Its odd that he says it works on Debian 10. My live machine (since sold) was running Debian 11 so perhaps its a Debian 12 and up issue.

Thank you so much! I'm looking through your files. I'll definitely let you know the results!

A "-" character preceding any letter inverts the direction of the operation.
 

The BK1120 seems to use AoE mailboxes to communicate. That is not supported by the ethercat master.
You have a big project in front of you should you decide to implement that.

I agree with Tommy that a reservoir on a daily-use table is kinda pointless.  But for an intermittent-use table I'm in favor.

We built a 5x10 table with a 4" deep pan.  Slats are 2", giving us the ability to raise the water level ~1"-2" above thin sheets.  We don't frequently cut with the nozzle below the surface, but it makes a noticable improvement when cutting stainless.  And reduces warping on thin materials.  And makes a huge mess because the nozzle isn't deep enough, but oh well.

Our reservoir is a large polyethelyne tank under the pan.  Takes up about 1/3 the length of the table.  We have a motorized ball valve for a drain and a 2-speed pump for filling.  The pump can fill the pan in just a few minutes - it's a big hot-tub pump - so you don't get annoyed waiting to fill the table. 

The ball valve is a powered-closed version, which means we can open the drain, shut the machine/control down and walk away without having to babysit the drain valve.

Our table is not in daily use - perhaps once or twice a week.  Here's why we like the ability to drain the pan:

• The shop full of other CNC equipment isn't nearly as humid.  Yes, the dirty plasma monster is in a separate section of the shop, but the humid air can still circulate to the 'clean' parts of the shop.
• The table is on casters (with locking feet).  We only move it a couple times a year, but draining the pan in to the tank makes dragging it out of the corner way less of a splashing disaster.
• It's easier to muck out the pan
  • The pan is not sloped, nor does it have a sump. I think those are pointless unless you have a complicated automatic, underwater rake.  Which means we don't get swarf/junk in our tank - it just drops to the pan bottom and sits there waiting for us to stop ignoring it.
  • If you've ever tried to dig out a deep sump packed with plasma crap, you'll never want to do it again.  That $hit is heavy and turns to concrete.
• Our plasma can double as a router table.  We have removable aluminum-framed panels that sit on top of the pan fram and connect to a vacuum system, and the plasma floating head assembly can come off and a 3kw spindle bolts in place.
  • Being able to drain the water is a must, otherwise the MDF spoilboards would disintegrate after a few days of the humidity.  Even though the top and bottoms of the removable panels are HDPE, any MDF on top turns to oatmeal if we forget to drain the water.
• Getting water to the table is sort of a hassle as the only source is ~60 feet away.  Hauling buckets sucks, so the less we have to do it the better.
• We use borax as an anti-rust agent in the water, and not having to mix up a batch as frequently is nice.

If you have problems with freezing, maybe look for a sous-vide heater that's adjustable to a very low temp. You don't need much heat, and the circulation function of a sous-vide dingus will go a long way towards avoiding a freeze event.

Oh, and the table is not controlled by Linuxcnc, which means it's horrible in every possible way and I'm ashamed to be associated with it.

I figure being able to quickly drain/refill the pan to fish out small parts is best reason for a reservoir, but I also worry about the pan freezing in the winter since the glorified shed it lives in is not heated. So figure when it gets cold, the water will already be in the heated reservoir, ready to refill the pan.

I'm thinking 12-15cm(5-6") deep. How much higher should the pan sides be than the top of the slats?

I appreciate your suggestions. I wanna hear them, especially the ones pointing out my potential problems. Mostly basing this plan on a few other large tables I've seen in person and forums, not youtube videos. The only reason why I even looked into underwater cutting is cause I think you prefer to cut underwater? I've only seen ones that that are up to the plate, not submerged. But apparently some plasma's cut under several inches of water so I figured I'd ask the experts on the linuxcnc forum.

I have some suggestions, you wont like them:
-Reservoir is utterly useless, unless you intend on using the machine about once every month or two, simple physics water evaporates and does so much more when it has a nozzle spewing 10000 degrees heat into it all day long. During summer here (35-40C) and heavy use, i have to refill every 2 or 3 days, meaning 2-4cm of water level is gone in that time. In general bigger table = less water level drop daily.
Having a water tap directly into it would be much more useful.
-You can cut underwater, easily, do not go above about 1-2cm deep with the torch, and that absolutely requires drying the torch whenever you do not use it as it will rust, quickly and badly. Everyday use should be fine.
-Roughly 15 cm deep would be nice (a lot less spill/spray over, 10 is very usable (mime are usually 10-12cm deep), and i would not go lower than 5cm on slats for up to 100A, 10cm for 200A and above.
-as for reservoir issues, see first paragraph.
Also, I might be utterly wrong here, but, stop watching youtube experts that built a single machine and now dispense advice like they are the "be all-end all".

I have a 20'x6'(6m x 1.8m) plasma that I'd like to convert to a water table. I plan on having a reservoir underneath that gets filled/drained with air pressure.
I have seen some water tables that have the water at the bottom of the sheet, but I've yet to see one that cuts underwater. How deep underwater does the plate need to be?
I guess I'm trying to figure out how deep the pan should be and how tall the slats should be.
The way the table is, it'd be fairly easy to make a 4"-6"(10-15cm) deep pan. It wouldn't be too hard to go deeper, but we're already at 100's of gallons and thousands of pounds at that depth.

My main reason for a water table is smoke control, but minimizing warping on sheet metal would be a plus.
I'm not certain I want underwater cutting, but I like the idea of it.

Some other questions.

How to keep sediment out of the reservoir? I thinking of having the last few inches of the pan go directly to the reservoir, with a sort of lip and screen. The upside of this would be easier fabrication, but that would also make the reservoir/pan one piece. Alternatively, I could use pipes, but I still don't know how I'd deal with sediment and I'm sure that would really increase the drain/fill time.

The building the plasma is in is unheated so I need a heater to keep the reservoir from freezing. I think a screw in or tri clamp element like you'd see in a residential water heater would be the best choice. How would I go about controlling the temp? I don't wanna reinvent the wheel if there are already off the shelf solution if anyone has a suggestion.

Any insights are appreciated.
 

I understand this currently comes with 8 digital inputs and 8 digital outputs, besides the analog I/O. If I later wanted to add additional inputs, would it be just a simple matter of stacking on additional input cards and updating my linuxcnc config, or would additional changes be needed?

Snowgoer- I get what your saying. I've heard enough "Can't you just...?" of my own. I know you can't please everyone, but I'm grateful for all your and everyone else's contributions.

I guess I'll see what I can do with axis. I do appreciate the plasmac statistics.
As a fabricator, most of my quoting involves chicken blood, planetary alignments and bs. I'll let you decide how much of each.

Does anyone quote by inches and pierces?

Sorry for double posting, but i forgot this trying not to forget to upload pictures, namely:
PlasmaC and QtPlasmaC have very detailed time logs, so if you have more than one of the same design to cut, cut one after resetting the timers and check how long it took after the cut, then you know exactly how long the rest of them will take.
This is magnificent for more than one off cuts.

Axis GUI, included with LinuxCNC has such a feature in "File>G code properties" menu:


It is fairly useful when you know what it actually shows, like the actual feed time, nothing else, so no G0 moves, no probing, no compensation for feed rate changes, etc.
Takes a bit of time to get used to it, so for simple stuff with not much pierces i just double that time, for more complicated stuff like 286 cuts on a plate i just wing it to 4 or more times the shown time. Works fine for rough estimates.

I've given this some consideration in the past. At first thought, I think most of the data is there, but I don't think any of it is neatly sorted out. There is just so much that goes into affecting an accurate estimation of run time that the effort goes very quickly from "that would be easy" to "holy crap, this is impossible". You have so much to consider. You have the main cut moves - lengths, velocity, velocity reductions, accelerations (and acceleration with regard to allowed deviation from paths), dwell times, delays, probe time, number of probes, etc. I am sure there is a "close enough" approximation. But I've also done this long enough to know that "close enough" will only satisfy some people, and others will be upset when it's off by several seconds, let alone several minutes.

Maybe I will think on it some more, but no real promises.

I've only seen this in real life on one plasma system (not LinuxCNC related) - we have a table at work that the software gives an estimation. It's so wildly inaccurate it's laughable.