Advanced Search

Hello,

I’m in the process of building a small but fast 3-axis mill and have some questions about potentially using LinuxCNC over EtherCAT with it. This is a very conventional design, with just servos and limit switches as necessary inputs/outputs.

I’m going to be using Delta B3 x/y/z axis servos with multi-turn absolute encoders and drivers, which are available in an EtherCAT configuration. I’m also going to be using a servo for the spindle motor, but it will be a different brand with an encoder and a normal driver, not EtherCAT.

My three primary questions:

1. If I decide to run the EtherCAT versions of the Delta B3 servos, what additional hardware would I need to get to be able to control a single non-EtherCAT spindle servo?
2. What configuration/setup issues can I expect to run into with this hardware? Is this a reasonable configuration that should be fairly well supported, or am I on the edge and can expect a bunch of tinkering to get it all working?
3. Are there any reasons to think that I may not be able to use real-time encoder data for the four servos for things like rigid tapping?
   
   Thank you in advance for any help you’re able to give me.
   
   Callum

What does the embedded gladevcp panel do?

knipknap wrote:

Sure, I already put that into the preamble of future gcode files, but I don't think that's a good excuse to leave the machine in an inconsistent state depending on how it was switched on.

from the docs

RS274NGC_STARTUP_CODE = G17 G20 G40 G49 G64 P0.001 G80 G90 G92.1 G94 G97 G98 - A string of NC codes that the interpreter is initialized with. This is not a substitute for specifying modal G-codes at the top of each NGC file, because the modal codes of machines differ, and may be changed by G-code interpreted earlier in the session.

So when you start LinuxCNC the the interpreter is initialized with RS274NGC_STARTUP_CODE.

JT

How can I configure my estop button on mpg pendent so that I need not to press estop and machine on button in LinuxCNC GUI. Estop and machine on controlled by estop button on MPG pendant.
​​​

All,

As with many things in the LCNC world there are hundreds of variations of setups for various machines. Mills, Lathes, Plasma, Laser, Warerjet, etc. The list goes on and on. There are several methods and hardware devices that connect with LCNC to drive motion control ECAT being one of them. While it is ignored by most due to the price overhead, there are many who seek to use this technology for the benefits it brings forth. The main one being a deterministic model that just works. Nearly plug and play. Very precise motion control. etc...

As most know who are familiar with ECAT each OEM of a hardware device must supply an ESI/XML file to describe their hardware to the CANopen bus. The schema is a hard model created by the EtherCat Foundation. Ever OEM must use specific data types, and specific registers in accordance with a standard. PDO 6040 for example. You get a total of 8(4 Rx and 4 Tx) as well as a slow bus set on the SDO channel which are updated at the 100ms tick on the DC(Distributed Clock). These standards are setup to ensure that all the data looks exactly the same. Say I have an Omron drive and a Delta servo on the same system. No worries. They use the same ECAT pipe and you can basically just use the same xml description for both nearly interchangeably. Now, there are abilities to use the SDO channels to send parameters, messages, etc. but those are not required. Each drive has their own set of those although most simply mimic each other overall. 

I will never pretend to be an expert, but I think that much of the discussion on this channel has to do with a misunderstanding of the problems ECAT tries to solve. ECAT is a simplification model. That means, that if ever device connected speaks the same language the actual system becomes nearly plug and play. ECAT is not designed for a system that fits the needs of the individual but the collective of users so that user A can get the same performance as user B. In order for that to happen ECAT made the OEM's who are registered ECAT hardware providers conform to a specific standard. The 5000+ members(OEM's) all agreed. So for the past 20 years, that standard has stood as the pedestal that makes ECAT such a popular approach to motion control. Speed and standards. 

All that said, LinuxCNC is an Open Source software. So is EtherCat. Simply because Open Source is open does not mean that some level of standards should not be employed to ensure each person who chooses the LinuxCNC or EtherCat system will have a solid and successful result. If the user wants a specific duty system, then they should be solely responsible for the development and maintenance of their custom system. That system may end up being the best practice, but most times it is not the case. If EtherCat is going to ever be a solid method to integrate servos with LCNC, then a standard driver must created that all registered servos can use to connect with LCNC. Currently, the Generic Driver works. But, that driver merely handles the PDO side leaving the SDO side alone as far as I can tell. 

So here are the pain points of EtherCat with LinuxCNC as I see them:

1. The Generic Driver works with most drives but is very simplified. Currently if your drive is not listed, there is no .h/.c driver specific to your hardware so you must use the generic version and good luck with the .h/.c drivers if you want to extend your usage of the drive.
2. If you use the OEM ESI, you must have a .h and .c file to accompany it or else it fails to compile. (NOTE: In most Masters the parse file merely uses the <Vendor> section to record it in the dictionary. The only thing the driver needs is the device info to build the OD(Object Dictionary. LCNC uses the drivers to create the required Hal pins for the device. As far as I can tell from the schema standards all registered devices use the same registers that are exposed to the bus.).
3. Homing is a drag. Even though the drives(Registered) have their own internal homing and merely need the master to say hey you, go home and let me know when you're done, many are trying to use the LCNC homing model. Using the LCNC homing method has to be modified to allow the drive to do that work. LCNC just needs to butt out for a bit. This has many trying to make a "custom homing method". Which I think has to be done, but as I see the code behind it LCNC is involved in the process at the micro or weeds level. LCNC should be at the macro level. Set OP6 mode and wait. Drive done, LCNC updates ABS machine position, and records the axis as homed. The method of how the drive did that "homing" is none of LCNC's business. Just that LCNC said, go home and the drive said, yeah like I did it bro. This is known as a separation of concerns. With EtherCat involved, LCNC no longer controls motion nor needs a closed loop feedback or even semi-closed. It is just passing messages it parses from your GCODE. Period. 
4. Drive Error Channels are not piped. These come form the SDO side on the slow bus.
5. there are way more so please add to the list...

All in all, LinuxCNC is already complex to set up. EtherCat was designed to not add additional complexity. Let's start discussing what is involved in creating a standard working driver that will parse properly any imported esi/xml file from the OEM's. There are thousands of them. It seems illogical at best to have this massive code base for each and everyone of them. And to expect for those files to be maintained. 

If the Generic file works, let's update the driver so that more than just simple PDO's can be parsed. Let's decide which SDO's to include or make optional that can be parsed as well. This way, we can write specific parameters like EG values, max velo, and read the error stream on failure. A truly generic but robust driver that works with 90% of all drives regardless of OEM. If the VendorName is set to Generic so be it. The dictionary saves it as that. But is it says, "Joey Bag Of Donuts", the driver should be able to stored that in LCNC as well as the productType in an accessible format from LCNC. Maybe a .var file? Then if in QtPyVCP, you can access the file and display the list of connected devices on the machine screen in a table. 

I sincerely hope this discussion brings real change that helps everyone now and going forward. LinuxCNC is not just free, but after 30 years of CNC control engineering the motion control output parallels Siemens, Fanuc, and Heidenhain. So much so that a lot of the code base for these high end controls comes from LCNC. Heidenhain especially. It would be awesome to have a system that any common man can build without having to sell his entire family to pay for it. 

Sincerely, 

Don

Thanks, I've had a look at the Leadshine offerings, they don't appear to be available anywhere.

Ultimately I did want a servo to drive the spindle, but I couldn't find one that matched my specifications. (single phase 220v supply, ~3kW, Ethercat, 4krpm+)

I did find the following:

www.oksa.co.uk/product/ecat-2074a-etherc...lute-encoder-master/

Which is a 4 channel BISS/SSI encoder interface for around £545. Which makes it cheaper than the beckhoff interface and encoder module. 10MHz capable counters.

Or a 3 channel ABZ input for around £273. (much cheaper than beckhoff) - but it can only count at 4MHz

www.oksa.co.uk/product/ecat-2093-etherca...tal-encoder-counter/

 

Using Linuxcnc 2.9.2. I am attaching the INI.

I have another system that runs on Linuxcnc 2.8.4, and it hasn't encountered this issue even once. Not sure if I am doing something wrong on the previous system.

 

Sure, I already put that into the preamble of future gcode files, but I don't think that's a good excuse to leave the machine in an inconsistent state depending on how it was switched on.

ok good, so you are using the correct component for your board for the STM32

What to make it work? I am not sure. I am not 100% sure its because you are using wheezy, but I think its very likely. The kernel looks like 3.4? Which is very old, and wheezy was released over 10 years ago. I didnt know of a solution

is the RT kernel RTAI? that could be why maybe

I have fresh install of latest Debian 12 (on quite old Intel Atom MB). I was following the docs, linuxcnc.org/docs/2.9/html/getting-start...#cha:Installing-RTAI in particular, but got errors, LinuxCNC install failed.

First, got this warning during execution of the install script:

W: Skipping acquire of configured file '2.9-rt/source/Sources' as repository 'www.linuxcnc.org bookworm InRelease' does not seem to provide it (sources.list entry misspelt?)

It got me worried, but I still performed the next step (sudo apt-get install linuxcnc). Got the following output.

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libgpiod2 libwpe-1.0-1 libwpebackend-fdo-1.0-1
Use 'sudo apt autoremove' to remove them.
Suggested packages:
  mesaflash onboard
The following packages will be REMOVED:
  linuxcnc-uspace
The following NEW packages will be installed:
  linuxcnc
0 upgraded, 1 newly installed, 1 to remove and 0 not upgraded.
Need to get 25.5 MB of archives.
After this operation, 676 kB disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 www.linuxcnc.org bookworm/2.9-rt amd64 linuxcnc amd64 1:2.9.2 [25.5 MB]
Fetched 25.5 MB in 5s (4,640 kB/s)   
(Reading database ... 281951 files and directories currently installed.)
Removing linuxcnc-uspace (1:2.9.2) ...
Selecting previously unselected package linuxcnc.
(Reading database ... 276444 files and directories currently installed.)
Preparing to unpack .../linuxcnc_1%3a2.9.2_amd64.deb ...
Unpacking linuxcnc (1:2.9.2) ...
dpkg: error processing archive /var/cache/apt/archives/linuxcnc_1%3a2.9.2_amd64.deb (--unpack):
 trying to overwrite '/usr/share/applications/linuxcnc-documentation.desktop', which is also in package linuxcnc-doc-en 1:2.9.2
Errors were encountered while processing:
 /var/cache/apt/archives/linuxcnc_1%3a2.9.2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


I understand that I've got two problems: linuxcnc not installed and RTAI kernel is not too (uname -v gives 1 SMP PREEMPT_RT Debian 6.1.90-1 (2024-05-03)).


Please, help me figure it out.

@Automata,

Yes, G64 P.. Q.. L..

Will the clothoid interpolation work for 9 axis G1 moves?
It is going to work, but we need someone who makes a tiny document how the rules are to achieve this.

I mean, i will code it following the document guide lines, coding steps.

So the document needs a few steps, what are the rules for interpolation on 9 axis. Wich axis first, when what
to do and so on.

Maybe you can make the document and think about it extensively.

Here are the results of a helix not doing a G2 continuity, G2 ... L0
Clearly you see sharp transition corner in yellow, this is bad for machine :
 

And a helix doing G2 continuity in the testfile of Robh,   G2 ... L1:
Yellow is transition from helix to helix. Red and purple, no transition corners visible.
Path is better for machine.

 

Well, I can help with both. I am working with LS Electric to provide some lab materials just for that fact. The hardware is affordable and LS has complete compliance with all cia_402 and EC ISO standards. With all options for setup available so a standard for all methods can be created in one file with zero need to "tweak" for special reasons. The only group who would maybe need to do some "tweaks" would be persons using robotics vs standard CNC use as they are typically 6 servo systems but only use 2 per axis to create XYZ.

I am currently going through all the LS docs and the lcec drivers. It is a lot of code. And a bit confusing. Once I have the hardware, I will work with Rod to hopefully have a single homing procedure for all methods in a single driver. Maybe an Enum to select the homing method. I can forsee a need to use an SDO though which in several of the xml's for Beckoff I/O use. But the few servo xml's available simply use the based RPDO/TPDO method. So that pushes that to the cia side on the slow bus. No worries, just needs to be figured out.

I am aware of Rod's work on that and his goals match my own. Hopefully with enough brains we can see some progress this year toward a solid integration using the ISO standards set forth by the ETCAT symposium.

Like I said, the idea of ECAT is determinism. Given a specific input a specific output is always realized in real time. The lack of free will and randomness is the secret sauce that makes it work so well and be so reliable.

Love the debate. Five thumbs up.

Poštovanje, zanima me da li popravljate strojeve na terenu? Odnosno da li bi Vi mogli pomoći spojiti stroj na LinuxCNC, imate li neki kontakt? LIjep Pozdrav, Dominik

Peter, yes i just tried 7i90 then 7i90hd so it was a name change. problem solved! I new you had changed the 7i80 to 7i80HD-16 or 7i80HD-25 but didn't think about that on this card

What version of linuxcnc are you using and can you post your INI file?