Advanced Search

Hi all,
here is a short update on the latest changes in LatheEasyStep:

Step list loading issue fixed
In some embedded QtVCP scenarios, the operation list stayed empty after loading a single step or a full program. The operation list binding is now more robust.

Safer retract/free-travel logic (lathe-specific)
Retracts are now context-aware per operation:

simultaneous X/Z where safe
groove/keyway: retract X out of material first, then Z
drilling/threading: retract Z clear first, then X
Current tool position relative to stock/chuck is now considered.
Extended chuck / no-go safety model
The program header now supports chuck-related parameters (size, workpiece type, clamping mode, profile) with automatic no-go zone calculation.

New machine/workshop profiles
Quick presets apply typical parameter combinations automatically (e.g. chuck + clamping mode + profile).

Preview improvements
The chuck safety area is now shown in the preview as a dedicated colored zone, including a legend entry.

Save/load extended
New header fields (chuck/profile/no-go/machine profile) are now properly persisted and restored.

My C enable was commented out by accident

Marcos wrote:

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.
 

If the toolchanger robot only requires point-to-point motion and doesn't require circular or linear interpolation, then extrajoints can be used. Basic safety chains, homing, and limits will work as for other regular joints. However, for motion planning, you need to connect the simple_tp or limit3 components. Their motion calls should be implemented in custom M-code (e.g., M100 P1.2 Q23 ...).

Hi,

Now that we won't be getting any support from the German PLC forum, I did some searching myself and found this interesting project. In my opinion, it could serve as a good template, as all the code I've seen so far uses a similar topology.

I would also like to emphasize that there is no need to reinvent the whole concept. We already have functioning components (CIA402; homecomp.comp) that form a good basis. Many thanks to @rodw and @MobiusToast for their excellent pioneering work. What is missing now is the further development of these components.
I fear that even this thread, with its good approach, will ultimately be forgotten.

For my part, I will take a different path.
Since I continue to have homing problems and have now ruled out EMC and configuration errors, I think the problem lies with the A6 itself. Yesterday, it took 3 minutes for the x-axis to start the reference run! 
I will now try to expand my system to include battery-buffered encoders.
At least according to the documentation, this should be possible. This would make homing obsolete.

 

Thanks a lot. I was afraid to hear this but at least I know where I stand now.

Made a start on getting the Schaublin tool changer running. I will use Andy's carousel.comp to control it.


 

That was unexpected. For all the world, it looks like this get stuck in libusb somewhere. After the "is Open" debug text, the code does the following:
1. Function call XhcWhb04b6Component::enableReceiveAsyncTransfer()
2. From XhcWhb04b6Component::enableReceiveAsyncTransfer() call Usb::setupAsyncTransfer()
3. From Usb::setupAsyncTransfer() call libusb_submit_transfer()
4. From libusb_submit_transfer() call libusb_unref_device()
5. In libusb_unref_device() print "libusb: debug [libusb_unref_device] destroy device"
6. libusb_submit_transfer() never returns is my guess
Maybe some deadlock inside libusb. Whether that would be from some bug in libusb or because of some improper handling in the xhc-whb04b-6 component, I cannot say. At least at the moment. I'll look into it some more, but not right now.

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