Advanced Search

Got a crash today. Seems to be the usual way. At mode and screen switch.I have seen that libusb debug printout several times before.Attach are the log and also usb.cc and xhc-whb04b6.cc to be able to follow my printouts. 

rodw wrote:

Affordable and 4500 rpm may not go together! Anything over 3000 rpm is hard to find and not affordable by many standards!

[EN]
The 4500 rpm is the upper limit from the sizing; in real operation I expect something more in the range of ~2240–3080 rpm.
Do you (or anyone else) have recommendations for 400V EtherCAT/CiA402 drives that are still reasonably affordable in that range?
I’d also be happy to look at solutions up to 3000 rpm if that significantly broadens the available options.



[DE]
Die 4500 rpm sind bei mir tatsächlich die Obergrenze aus der Auslegung, ich erwarte im Betrieb eher ~2240–3080 rpm.
Hast Du (oder jemand anders) Empfehlungen für EtherCAT/CiA402-Drives in der 400V-Klasse, die in diesem Bereich noch „bezahlbar“ sind?
Ich würde mir auch Lösungen bis 3000 rpm anschauen, falls das die Auswahl deutlich vergrößert.

Hi Hakan,

That’s a very interesting direction.

An external_homing method handled by motion/motmod — with limits, time supervision and synchronized gantry constraints — would definitely be a robust long-term solution. The idea of a freewheeling/follow-feedback mode in motion is also conceptually very clean.

However, changes in motion/motmod are a much larger step. They require core discussion, review and consensus, and can easily turn into a longer-term architectural effort.

Right now my plan is to stay focused on the original scope of this thread:

• ]Finalize a clean modular CiA402 stack (PDS manager + opmode modules + drive-agnostic app layer)
  • Validate everything in SIM
    • Then test and stabilize it on real hardware
      
      My short-term goal is to get it to the point where it becomes “boringly stable” on at least one real drive. Once that is achieved, I think it makes much more sense to revisit motion-level enhancements like external_homing or a freewheeling mode.
      
      Otherwise we risk expanding the scope too early and spending a lot of time discussing architecture before finishing the current layer separation.
      
      If we decide to explore motion-level changes seriously, I think it would be better to open a dedicated thread for that topic, since it would likely require deeper discussion and take some time.
      
      For now, I’d prefer to close the CiA402 separation work first and build from there.
      
      — Marcos

Hi Szolkaa
I own two Lichuan closed loop ethercat controllers. One with 4 motors, one with 1 motor.
Technical specs:
- Lichuan CL57E-4A (4 x closed loop)
- Lichuan OLCE-57H (1 x closed loop)

I tried your genius configuration tool. By importing the xml I get an error. 
Did you see any chance to get the both controllers running with linuxcnc?
Greetings Lars

root@LinuxCNC:/home/linuxcnc/Downloads# python3 XML_Generator.py 
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.13/tkinter/__init__.py", line 2071, in __call__
    return self.func(*args)
           ~~~~~~~~~^^^^^^^
  File "/home/linuxcnc/Downloads/XML_Generator.py", line 149, in load_esi
    self.convert()
    ~~~~~~~~~~~~^^
  File "/home/linuxcnc/Downloads/XML_Generator.py", line 198, in convert
    f'       <pdoEntry idx="{e["idx"]}" subIdx="{int(e["sub"]):02}" '
                                                 ~~~^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '#x0'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.13/tkinter/__init__.py", line 2071, in __call__
    return self.func(*args)
           ~~~~~~~~~^^^^^^^
  File "/home/linuxcnc/Downloads/XML_Generator.py", line 149, in load_esi
    self.convert()
    ~~~~~~~~~~~~^^
  File "/home/linuxcnc/Downloads/XML_Generator.py", line 198, in convert
    f'       <pdoEntry idx="{e["idx"]}" subIdx="{int(e["sub"]):02}" '
                                                 ~~~^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '#x0'
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.13/tkinter/__init__.py", line 2071, in __call__
    return self.func(*args)
           ~~~~~~~~~^^^^^^^
  File "/home/linuxcnc/Downloads/XML_Generator.py", line 149, in load_esi
    self.convert()
    ~~~~~~~~~~~~^^
  File "/home/linuxcnc/Downloads/XML_Generator.py", line 198, in convert
    f'       <pdoEntry idx="{e["idx"]}" subIdx="{int(e["sub"]):02}" '
                                                 ~~~^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '#x0'
root@LinuxCNC:/home/linuxcnc/Downloads# 
 

 

A new homing method, external_homing. Can box in motion with limits and time.
A variant could be external_synchronized_homing for gantry homing.
With additional limits on start positions maybe and max difference in position.
And so on. Done by motion/motmod. Communicates with pins to the drive component as usual.

Maybe also a new freewheeling mode and pin for motion/motmod.
For opmodes that disconnects the position.
Position is usually right from the drive even when opmode changes.
But you don't need to control the position, just follow it.
I think one need to go over all  opmode switches and see which situations can appear.
 

mmm. interesting

I may wind up making it self contained, as not all my customers will use linuxcnc.

it could run linuxcnc self contained. or we could make it much more simplistic on an arduino.

The way the system is now its down to 2 coordinated linear axes, one fixes linear axis (most likely to be an air cylinder) and one for rotating, which might be best served with a servo axis. not sure yet.

thanks

Okay. Once you get a crash, post the output here and we can try to work it through together. Please ensure that you have some print statement in place of the commented out assert call, so if it fails there, we know about it. Something like:

I am a long term fan of LinuxCNC and FreeCad. Unfortunately I am being forced by a client to try Blender 5.0.1 with FabEX 3.0.1 add on because they like the pretty graphics.  In 50 years of computer work I have never seen such a learning curve  non standard monster....yet nifty graphics. My problem is this: I have watched numerous tutorials, noted all the undocumented hot-key commands and slowly created a simple .blend file to machine a simple cylinder to test the gcode this thing creates. Blender Fabex will not create the toolpath; issues some error about version compatability. Do any of you folks know where I can get a SIMPLE WORKING .blend file example already setup for FabEX to do ANY kind of milling to see if can even get the application to run at all. I am VERY frustrated with Blender.  Thanks in advance.
I

Because the OP is on the Ethercat bandwagon (as are the commenters),
I have wondered about a seperate Ethercat component that does not consume an axis. I was mostly thinking about spindles but it might be able to morph into something with position control.


EDIT Running it on a seperate thread may give you enough independence...

Affordable and 4500 rpm may not go together! Anything over 3000 rpm is hard to find and not affordable by many standards!

One other possibility I considered, if it is possible to run just one at a time?
Could it then be done pausing the one and temporarily switching kinematics to run the other set of axis... say, toolchanger?

I've been thinking about this for some time.

Obviously the easiest way is probably going to be to run a second LinuxCNC pc. (Assuming I'm doing everything in LinuxCNC.)

Then I was thinking about the possibility of running a custom multi-instance capable tp component consisting of something like:
GUI <-hal-> [tp.0, tp.1, tp.2] <-hal-> [trivkins.0, scarakins.0, scarakins.1] <-hal-> I/O (mesa, lcec, etc)

Definately re-inventing most of the wheel. Can we make it any harder?

Thanks, that's basically what I thought

LinuxCNC has a single realtime motion module (motmod).
All coordinated motion and joint updates go through that one trajectory planner and queue.
Even if you configure additional axes (U/V/W etc.), they still belong to the same motion instance.
There is no concept of a second independent motion channel inside one LinuxCNC process.

Industrial controllers sometimes give the impression that this should be possible because they support true multi-channel motion. For example, platforms like Omron Sysmac can run multiple independent motion groups or program contexts in parallel within the same controller. That capability is built directly into the motion kernel.

LinuxCNC, however, is architected around a single motion instance per process.

If you need the tool robot to move while the main machine is cutting, the practical solutions are:

• Run a second LinuxCNC instance / second controller for the tool robot and handshake via IO/fieldbus.

• Use an external PLC/MCU/drive sequencer for the robot and trigger it from LinuxCNC via M-codes or IO.

A “HAL-only second planner” is technically possible, but then you own all the safety, limits, interlocks and coordination logic yourself — and it tends to become fragile fast.

So i had a craaazy idea for a little robot tool library.
Wondering how you would implement it in linuxcnc.

So we have our XYZA on our cnc. lets reserve B just in case we ever need a 5th.

That leaves 4 more axes available.
Our little tool robot will have an x2 y2 z2, and a x3 (fixed motion, likely air) and C do pivoting the gripper - again fixed motion.

Basically it is a cnc of its own, and needs to operate while the main machine is cutting so it can sort and stage tools. This is different from using C for an atc platter that is actually coordinated with the main machine.

How could we do this?can we decouple these new axes from the main motion as a "channel" ?