Advanced Search

Thanks

Just to tidy up this thread, here is a pic of my working PB Lathe setup...

 

But the main question is still open: is there any way to tell the backplotter where the centre of rotation is, when the rotary chuck is not at machine Y=0?

In my case the chuck is fixed at Y=700mm. The backplotter always rotates around Y=0 (machine origin), so the wrapped toolpath displays as a large circle far from the actual machine envelope instead of showing correctly near the chuck.

I have already seen the 2013 thread where andypugh said there is no solution.
Is this still the case in 2.9.8, or has anything changed since then?

Yes, for hal scaling and output and encoder count direction, but i do not know if that works for geometry.

I use baking soda as rust inhibitor, it does a pretty good job and even when water evaporates, it does not, so adding more is not necessary for a long time.
It also remains attached to slats/table when no water is left, so had no rust issues for many years.

grandixximo wrote:

I've used debian 10 11 and 13
I skipped debian 12 this is for internal timing release reasons, not because 12 had anything wrong with it. I did not notice on my hardware considerable differences between debian releases. 

I don't really see any difference between 12 & 13 (everything is 13 here). From earlier feedback on the preempt_rt email group, The preempt_rt network latency issues were most likely introduced in kernel 5.9 and Debian 11 had 5.10 but because Linuxcnc never released anything on 11, the issues did not  appear until Debian 12 which I used from the original beta release.

grandixximo wrote:

I'm also on the discord, and I am fluent in Italian 

discord.gg/WwMfD9v9M

If your Italian friend wants to hop in, I'll be glad to help him out.

Thanks I've passed that on. He'll probably call himself frk (Francesco)

This is not related to the phasing.
Or perhaps it is, on the way that clocks have started to run with different speeds.

You can switch on debug "ethercat debug 1" and watch the DC time difference between slaves slooowly converge.

It's part of the startup of slaves
gitlab.com/etherlab.org/ethercat/-/blame...e=heads&page=2#L1480

The server issues 5000 sync requests, one every millisec, and waits until clocks are within 10 microseconds.
If they aren't, you get the message. The slaves' clocks will eventually converge.

I had this issue, was unable to fix or even poke at it, and then suddenly it went away.
I suspect it has something to do with ethercat master version, but since I was unable to
diagnoze it, I really don't know.

I'm also on the discord, and I am fluent in Italian 

discord.gg/WwMfD9v9M

If your Italian friend wants to hop in, I'll be glad to help him out.

I've used debian 10 11 and 13
I skipped debian 12 this is for internal timing release reasons, not because 12 had anything wrong with it. I did not notice on my hardware considerable differences between debian releases. If you have issues please share your configuration, be clear about the issue, share as much info as you can, and if you are not using my fork code, you most likely HAVE phasing issues. Those maybe effecting OP times, or motion, or nothing, it depends on the hardware. Will update to my fork fix everything? No, most definitely NOT everything, but I am sure phasing will be as proper as it can be on your system, and you will have debug pins to analyze performance which you can share, run halscope and halshow, see the ecat.0.xx pins, so that we can get to the bottom of the issue.
If Scott was still in the game, he would probably merge it and make a release. I would advise everyone to update, and if you have any issue, I will be here or on GitHub for support.
 
TL;DR
My fork does not magically fix all issues, but it does fix some, and gives you pins to benchmark your setup. Please build and install my fork, then test, and share your configuration and test results if you have issues and you want help.

I think 4" deep is enough even less if you have to. I found best quality was with the water touching the bottom of the plate (to 5mm below) but often evaporation took it down lower. Enable preflow to get air flowing before starting a cut to blow the water away from the torch. Using commercial quench, I only emptied the tray every 6 months or so and just kept topping it up as the active ingredient does not get lost.

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.