New LinuxCNC-Ethercat git tree

The problem is that there are probably hundreds of things that could go wrong at any point, and we don't always know which ones are the most likely. Right now, the main point of most of our error messages is simply to provide debugging data, along with enough information to figure out where in the process things broke. That's fine for development but (obviously) not a great user experience. It's part of the process of improving things, though.

Once things stabilize a bit more we can work on improving the error experience.

Unfortunately, I'm still in the "break things more often" phase while doing cleanups and backfilling missing hardware support. Hopefully that'll slow soon.

@scottlaird

Awesome work…  I know you and Rod Webster have gotten this all working much easier, but I still like to do the source builds just as a backup.  This morning, I did a quick build of LCNC 2.9 using Bullseye with LXQT and your branch of /linuxcnc-ethercat/linuxcnc-ethercat.git    Everything is working correctly without any build issues.  I like that you have the “realtime.mk” file fixed, that totally streamlines the build.  I’m overloaded with work, but when I get time I will amend the “source build sticky” and replace Sascha Ittner’s link as you are definitely are making things happen.  @tommylight (I will get rid of the CAPS, I know you hate them)

Also, if you need more Beckhoff terminals for testing, I am more than willing to send you some.  I have all types and can generate a list of what I have.   I have several test setups and can send you a complete setup if needed with everything mounted on a DIN rail and ready to plug into 110V wall outlet.  

Once again, thanks for taking your time to make all of this happen it is greatly appreciated by all of us!!!

Thanks! I'm not sure if I'm missing anything substantial right now, other than maybe some of the EL5xxx encoder modules, but they're rare and expensive. You can see my current test hardware XML in Github , plus I have a few other things kicking around.

I have a backlog of a few different Beckhoff modules that I have but don't have drivers, you can see Github issues for them .  I'll probably go through those once I finish the CiA 402 work that I've been doing for the past week or two.

If there's anything specific that you (or anyone!) want to see supported, please open a bug in Github.  It's a lot easier to produce drivers if I have the hardware on hand, of course.  For people without Github accounts, feel free to mention something here and I'll try to create a bug eventually.  I'd rather work on drivers for hardware that people actually want rather than random code that no one may ever use.

@Coebett
With this stupid forum editor I recommend that you write your complicated long post in a text editor off line then when updates are required update the text file before pasting into the forum.
I keep my ethercat instructions in google drive.

It is amazing what @Scott has done now. I am looking forward to seeing his CIA402 drive for the ECT60.
Then the only thing missing will be a Homing component for CIA402 to complete the collection!

From rodw: „It is amazing what @Scott has done now. I am looking forward to seeing his CIA402 drive for the ECT60.
Then the only thing missing will be a Homing component for CIA402 to complete the collection!“

Absolute agreement… Thank you Scott! Excellent job…

scottlaird wrote:

Thanks! I'm not sure if I'm missing anything substantial right now, other than maybe some of the EL5xxx encoder modules, but they're rare and expensive. You can see my current test hardware XML in Github, plus I have a few other things kicking around.

I have a backlog of a few different Beckhoff modules that I have but don't have drivers, you can see Github issues for them.  I'll probably go through those once I finish the CiA 402 work that I've been doing for the past week or two.

If there's anything specific that you (or anyone!) want to see supported, please open a bug in Github.  It's a lot easier to produce drivers if I have the hardware on hand, of course.  For people without Github accounts, feel free to mention something here and I'll try to create a bug eventually.  I'd rather work on drivers for hardware that people actually want rather than random code that no one may ever use.
 

Could you check how much work this would be Separate LRD/LWR commands ? Hardware to test can be arranged.