Advanced Search

I tested the errorhandling branch by modifying the requestManaulMode back to the original. Then I can get the dongle to disconnect reliably. While I maybe did not do exhaustive testing, the dongle reconnected successfully every time I generated a disconnect. So at least based on this your code is working as expected.

Also with the original code, the pendant would reconnect for me if I simply removed the assert statement. I know that no "restart" is triggered from that alone. But because the USB device has been disconnected, the libusb_control_transfer will fail just a few moment later, and that will trigger the restart. For Hakan it didn't reconnect, but that was because it segfaulted in libusb. Anyway, now the assert statement is gone and there is some proper handling of the libusb_submit_transfer errors.

While you are there in the setupAsyncTransfer function, the libusb_fill_bulk_transfer() should really be a libusb_fill_interrupt_transfer(). If you do a lsusb -vvv, you see that endpoint 1 IN is really an interrupt endpoint:The bInterval means it should be polled every 2 ms (for a full speed device, as this is). I don't think that is guaranteed by a bulk transfer. And the interrupt transfers should also be given higher priority on the bus than bulk. I'm not saying that using bulk transfer causes issues. But because we have also had disconnect that are in my opinion not related to mode switching, it's at least possible that using interrupt transfers instead of bulk could improve the situation. And it's the right transfer type to use...

I sat for some fifteen minutes and tried my best to make the xhc fail. The errorhandling branch.
It works fine. The movement I used to make it fail is now blocked. And for the rest I just works.
I tried things that takes a bit of time like switch screen that used to be a problem.
Not a proof it always works, but I am unable to make it fail.

 

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:

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

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

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).
 

In my case I had a deadman's switch that had to be held down to enable the jog wheel on the pendant so I set teleop mode when that button was pressed.  I don't think you should allow just jogging the wheel to change modes. There are some safety rules around this stuff. And yes having to switch modes to jog on screen or a pendant is frustrating but probably for safety.

The current component tries to change to manual/teleop mode even with a program running/paused. The changes made by Hannes prevents that. However, if a program is not running/paused and you start jogging, it will change to manual/teleop mode automatically. It could of course be discussed if the pendant should be "allowed" to do this just by jogging the wheel. But the PR by Hannes is really mainly bugfixes, so I would presume that it's best not to alter the behavior of the pendant more than necessary.

I have not been following this but if the system fails with a program running, there is a fault with the driver logic. Jogging should not be permitted unless the machine is in teleop mode and programs are not permitted to run in teleop mode.

The driver could request teleop mode with halui.mode.teleop and this will prevent a program from running. I did this with a hard wired pendant. Gmocappy is a good gui to demonstrate this because setting teleop mode makes it display the jog buttons.

The assert statement is setupAsyncTransfer() is the "big" issue. Simply removing that causes the reconnect to be triggered when trying to send a display update. For me that reconnection works without problems. For Hakan, it gets stuck/segfaults in libusb after reconnect. Somewhere along these lines:
forum.linuxcnc.org/38-general-linuxcnc-q...ment?start=80#343687
It would of course be good to get to the bottom of this. But since I can't reproduce this, it's a bit difficult to debug.

Both myself (with the original firmware) and Hakan can trigger the disconnect reliably by using the original component and jogging while a program is running.

On the development computer, I use the LinuxCNC 2.9.8 iso image / Debian 13. That one has libusb 1.0.28-1. I'm not at that computer right now, so cannot check the kernel version. But it's the stock one from LinuxCNC 2.9.8 iso (unless "apt upgrade" has updated it).

Normally, you anyway don't want the program or MDI command to stop because you accidentally jog, so I figured this is a good choice, even if it would switch to manual. Which it doesn't do anyway, at least in my case.

I did not read the whole thread in detail. But it seams you have issues with libusb_submit_transfer() and the assert afterwards? According to the manual, this function is allowed to return disconnected: manpages.debian.org/unstable/libusb2-dev/libusb.3.en.html
This should be fine, we should handle the error, cleanup properly and try to reconnect. Worst case, you have to do is disconnect the dongle and reconnect it again. I can look into that.

Meanwhile, do you have a way to reliably get the device to disconnect? Otherwise, it is always hard to see if a fix is really a fix or just the device behaving nicely for a few hours and then failing again.

@Hakan: I see you have Debian 12 (So libusb 2:1.0.26-1 I guess, libusb-1.0 is the package name, not the exact version). Did you try Debian 13?
@Finngineering:
Which Debian version do you have? Kernel version? Libusb version?
I have Debian 13 stock, libusb 2:1.0.28-1

Yeah, it appears libusb_context is defined in libusbi.h, which is not part of the normal "distribution package". I missed that. There are several compilation defines/options for libusb, which makes a bit more difficult to understand exactly what is happening. But I do think that your libusb_set_log_cb() should have done the trick (unless for some of those compile time options).

It was a little bit strange from the start that it succeeded to print that debug message and only afterwards seemed to hang (which we now know was a segault). I wonder if there could be something wrong with the handling of variadic (=any number of) arguments, which messes up the stack and in the end gives the segfault.

I had a second look at the issue you created a couple of years ago. And yeah, already there you identified libusb as a problem. I don't think really put much thought into that the first time I read it.

Hannes have made a pull request which is waiting to be accepted into LinuxCNC. Andypugh bought a similar pendant and will test the code once he receives the pendant. I guess if he is happy the PR will be accepted. Maybe in 1-2 weeks, is my guess.

I don't think it's possible to switch to manual mode while a program is running or paused. Which is what Hannes version checks for. I presume that if the program is running/paused, it needs to be stopped prior to making the mode change. But I have not verified that. If you are not having a program running/paused, then jogging should change to manual mode.

I tried that already, there is no access to log_handler.
struct libusb_context is not defined, only the pointer to it.
I tried with 
in process(), but no change.
There was a new message when restarting the connection from 
and that didn't crash even if it uses the same underlying log_v function.
I leave it like that.

The problem has been the assert statement. But I tested to remove that some two years ago
(the github issue) and failed in the same way it does now. But in general the assert is what
people experience, I understood.

I'll test Hannes' version next.

Edit: Tested, it avoids the mode switching altogether. I think that is perfectly fine.
I don't expect to switch to Man mode and jog when I'm running a program. Could happen
by mistake even. If I feel a need to switch to Man I'll designate a button for that.
I have a vague memory I did that on the previous generation xhc.

Is it in a shape to go into linuxcnc repo? I think it should end up there.