Advanced Search

In LinuxCNC, the XYZ tool offsets applied via G43 work correctly for the tool.
You can apply them inside M6 by executing G43 inside remap, or separately — it doesn't matter.



The error you are receiving indicates that you have changed the tool orientation (rotated the WCS). The post-processor checks whether your MachineConfig can perform an ABC coordinate system rotation, but you most likely have a standard 3x configuration.

However, to use drilling in planes other than XY (G17) without WCS rotation, you will need to change the post-processor logic in Fusion 360. The standard LinuxCNC-EMC2 post does not allow this. The standard 5x or 3+2 post will not work either as they rotate the coordinate system, which is unnecessary when drilling in a plane other than g17.

There are different ways to implement this:

1) Classic 5x/TCP rotates the coordinate system by controlling the AB axes and TCP activation codes — this is probably too complicated for your machine.

2) Allow tool vector orientation other than Z – this is often used for rotary/angle heads on milling machines.  To do this, you need to modify the postprocessor. See this topic for more information: forums.autodesk.com/t5/hsm-post-processo...n-stock/td-p/8911668

In this case, you do not need to select 'Tool orientation' in Fusion; WCS remains the same as in the setup.


3) The strange but common logic of posts for some furniture machining centers with drilling blocks that you can find looks like this: the g54 offset is defined for the XY machine plane, other offsets are used for side surfaces, and then the CNC recalculates. The control program looks like a cardboard box unfolded onto a plane. I don't think you'll want to use this strange proprietary logic.


I recommend adding mandatory checks:
In the post-processor:
- Check which tool numbers can be used in planes other than the XY plane.
- Check that side tools (T for the ZY plane) are only used for operations on the ZY work plane.
In the CNC:
- check that the XYZ tool offsets for side tools are not equal to 0 (this check can be performed inside M6).

See if you can find something in Australia, otherwise Europe (Germany and Portugal) or USA.
Portugal uses DHL for all their shipping, so it is fast but will cost a bit more.
Portugal
www.eusurplus.com
Germany
www.welectron.com
USA
www.mesanet.com
www.mesaus.com

Yes, but not easy as it does require changing the PC and controllers and IO boards if any.
You can not just install LinuxCNC as the existing PC is probably to old and the controller will most probably not be able to communicate with LinuxCNC.

I had to make a component that handles the spindle.0.index-enable signal.
Here is how it is supposed to work from this component linuxcnc.org/docs/html/man/man9/encoder.9.html
The index-enable is I/O pin which isn't supported by EtherCAT, only I or O pins.
github.com/MetalMusings/MyOwnEtherCATDev...musings_encoder.comp
Three lines to connect it in the hal file
github.com/MetalMusings/MyOwnEtherCATDev.../linuxcnc/Turner.hal
For the EL5101 it looks like you need to work with the control and status words instead of the pins I used towards the device.
Hope it isn't too confusing.

 

The crashes I got was after removing the assert() in setupAsynchTransfer().
When that condition happened, the code waited three seconds and tried to to re-establish
communication. I then got a segv crash from within libusb forum.linuxcnc.org/38-general-linuxcnc-q...ment?start=90#343894
I tried on two different computers and got the same crashes on both. Both debian 12.13, gcc 12.
When i upgraded to debian 13 and gcc 14, there are no more crashes.
I also don't get that debug message from libusb about destroying device.
"Only" changing the gcc compiler version did change things to the better.

My way of get the xhc component to fail is to increase the loops to 100 in hal.h,
start G1X-200F100 in MDI and once that is slowly running, I spin the wheel very fast in the Z direction,
or any direction, but Z is safe.
With default value of loops it takes some tries to get it to fail, and with loops 10 it is almost impossible to get it to fail.
After it fails it usually restarts after a few seconds. Unless the libusb crashes it with segv as it did with gcc 12.

I did try your component yesterday for a short time and it never failed. 

So, it should be solved. Ready for testing.
In the case libusb_submit_transfer() returned an error and you remove the assert, the whole xhc-whb04b-6 module would just do nothing any more. I think that's what you observed.
I tested it by pretending an error happens, so not 100% what you have:

Great and thanks for your quick replay. I´ll check

Hi @NWE,

Sorry for the late reply — I was a bit busy the last days.

The CiA402 semantic layer is now running in simulation using a HAL drive stub and the core parts are behaving as expected (PDS state machine, controlword ownership, homing supervision, etc.).

The next step is integrating it with real hardware via lcec.

I don't currently have EtherCAT hardware locally, so the plan is to prepare a configuration for your two drives and let you try it when convenient.

I also made the repository public so you can see the current architecture. It is still experimental and not finished yet, but the simulation layer is already working.

Repo:
github.com/MarcosDuqueCesar/linuxcnc-cia402-layer

I found an other issue while trying to test the error handling. Please wait with testing.

Hi kostas,
it's possible, there are already generated parts to drive the boards without linuxcnc (from Python/C, over MQTT / JS / ROS).
there is no generator for a microcontroller master, but it's not so hard to use the C client as an template for that.
But if you want to drive motors in Position mode, you need an PID controller inside the microcontroller, not so hard, but you need to write one.

Olli

That WHB component is somewhat a rabbit hole... I tried to do proper error handling, can you test it?
github.com/hdiethelm/linuxcnc-fork/tree/...fix-v2-errorhandling
The proper way of testing would be:
1. Get this version to fail reliably: github.com/hdiethelm/linuxcnc-fork/tree/xhc-whb04b-6-fix-v2
2. Now test this version: github.com/hdiethelm/linuxcnc-fork/tree/...fix-v2-errorhandling
Otherwise, you can never be sure the change made any difference. I now that is often not that easy.

Looking at the code, just removing the assert() probably can result in segfaults in libusb as long as the error is not handled properly.

Note that even with my changes, it is not really how you would do it in a nice way but it should work I think. I am not able to reproduce your issue, so I can just guess and try to do better error handling.

@rodw: Jogging in manual mode is fine. My machine can not jog in teleop mode due to I have two Y axis servo motors. The only thing the WHB component does after my PR is:
- Change to teleop mode if not homed (which fails on my machine but on others, it will do that) -> You can jog before homing any special action
- Change to manual mode if homed AND program is idle -> You can jog after homing without any special action

Hi everyone,
i have 2006 Spinner TC65MC lathe machine with Sinumerik810D, i cant use this machine becaus i dont know Shopturn and only CAM progrmming with small using . Can i change it to Linux CNC ? If yes how i can do this ?

rodw: I tend to agree that jogging should not be possible by accident. However, I would personally keep that kind of behavior change separate from the bugfixes in the PR. I just fear that changing behavior makes the PR more likely to be not be accepted. But I don't really know, and it's Hannes' PR after all.

Hakan: Great if you got rid of that libusb issue. Then unless somebody else experience the same issue, I think not much need to dig deeper.

You are right, rodw, and I don't particularly like it. But that's how it is.
That part can be taken out, for sure.

Some news. I think it is now narrowed down to debian 12 and probably gcc 12.2
Hannes, your question on trixie, I thought I was on trixie on my development pc, no I was on 12.13.
And suspicion about va_args.
So I upgraded to trixie and gcc 14.2.0.
Recompiled, and now it doesn't segv anymore.
It continues after a short break, like it should.
The problem is in libusb1.0 when compiled with gcc 12 (if I understand right).
 

Thanks! I had completely forgotten to add the "user_dro_display" files to my machine configuration. Copying them over from the sim files fixed it.