xhc-whb04b-6 code is sprinkled with assert() and fails occasionally due to that. Please remove assert() with NDEBUG because the code does the right thing without assert()

[MetalMusings]

Here are the steps I follow to reproduce the issue:

1. Download and install linuxcnc on debian as a package in the standard way
2. Start linuxcnc and use the xhc-whb04b-6. After a random time, hours perhaps, it stops responding
3. I don't have the error message here but I have searched and found that this is the line that triggers the xhc-whb04b-6 module to exit:
   assert(0 == r);
   line 460 in https://github.com/LinuxCNC/linuxcnc/blob/master/src/hal/user_comps/xhc-whb04b-6/usb.cc
   in the function
   bool Usb::setupAsyncTransfer()

This is what I expected to happen:

If it was unable to setup async usb transfer, it should do some retrying or so.

This is what happened instead:

The hal module stops. It isn't possible to unload or in any way repair this (afaik).

It worked properly before this:

(If the behavior changed after making a particular change in hardware or
software, describe the change you think is responsible. E.g., "after upgrading
from LinuxCNC 2.7.3 to 2.7.4")
I got a new xhc whb04b-4 the other day, so I have always had this problem with the new pendant.

Information about my hardware and software:

I am running 2.8 from apt archive.
I have also downloaded the developer source code and searched files and recompiled.
The issue is in both those versions.
The solution is simple. Disarm the assert() function with the NDEBUG directive.
Because when this is done, the code does the right thing. It tries to reconnect and re-establish
functionality.
I have gotten an error in setupasynctransfer, the code handles this fine, and re-established functionality.
I am now running a version with NDEBUG and, yes this is how it should be.

[burak1000]

thank you very much for this . i will try these and write here the results.
have a nice day

[petterreinholdtsen]

[HakanBastedt]

The solution is simple. Disarm the assert() function with the NDEBUG directive. Because when this is done, the code does the right thing. It tries to reconnect and re-establish functionality.

For the record, disabling bogus asserts with NDEBUG is the wrong approach. If the assert should not trigger, the assert should be removed or perhaps rewritten as a test logging something instead. The behavour of the code should be the same way in debug and no-debug builds.

…

-- Happy hacking Petter Reinholdtsen

[burak1000]

How can i do add nbebug . İ tried compile the linuxcnc from source code but its too hard. Pls help

[burak1000]

Or İf i needed only so file can you share with me thank you

[petterreinholdtsen]

[Burak Yeler]

How can i do add nbebug . İ tried compile the linuxcnc from source code but its too hard. Pls help

You can locally add a '#define NDEBUG 1' at the start of the file to test the change. It need to be before any '#include <assert.h>' is happening. Such change is only useful for testing, and should not be used in the default build.

…

-- Happy hacking Petter Reinholdtsen

[MetalMusings]

There are changes to this in the later versions, I don't think the assert()s are there anymore.
I still get occasional hangs of the whb04b-6, but it seems to come from libusb now,
something there takes too long time.
It always happens when there is a large screen modification in qtdragon.
Such as when initiation a jog, but is in Auto mode. I guess the rearrangement of screens from Auto to Man mode
takes too much time or effort and it affects the usb connection. But just a guess.

[burak1000]

İm using latest version of linuxcnc and i using qrdragon_hd too. How can i fix this. Pendant works perfectly but after some time linux cnc relase whc 4 Eki 2024 Cum 13:16 tarihinde Håkan Båstedt ***@***.***> şunu yazdı:

…

There are changes to this in the later versions, I don't think the assert()s are there anymore. I still get occasional hangs of the whb04b-6, but it seems to come from libusb now, something there takes too long time. It always happens when there is a large screen modification in qtdragon. Such as when initiation a jog, but is in Auto mode. I guess the rearrangement of screens from Auto to Man mode takes too much time or effort and it affects the usb connection. But just a guess. — Reply to this email directly, view it on GitHub <#2237 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD7ZW5MFYLNHL7GOGBYYR6LZZZTGNAVCNFSM6AAAAABPKXGM7SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJTGM2TMNJTGI> . You are receiving this because you commented.Message ID: ***@***.***>

[MetalMusings]

I have no solution. I try to remember to switch from Auto to Man mode on the screen.
Other than that, I restart linuxcnc at a convenient time.

[burak1000]

yws

I have no solution. I try to remember to switch from Auto to Man mode on the screen. Other than that, I restart linuxcnc at a convenient time.

yes you are right when machine running in auto mode if i turn wheel qtdragon cant change mode several times and error happens. i will found the problem. thank you.

[andypugh]

It seems like a proper solution is needed, but as a workaround you could make a mini HAL file that unlads the component, the reloads it and re-makes the HAL connections.

The hal command "unload" will unload both userspace and realtime components by name.

To connect to a running HAL session at the command-line use

halcmd -kf

You can type individual commands by hand (loadrt, loadusr, net, addf, linkp, unlinkp, show etc) or load and execute a file with "source".

So maybe

halcmd -kf
source reconnect.hal
exit

[MetalMusings]

Reminds me - I actually have this. All startup hal commands are in one file including the loading of the xhc-whb04b-6 module.
So I can do
halcmd unload xhc-whb04b-6
and then
halcmd -f xhc-whb04b-6.hal

xhc-whb04b-6.hal is the file that gets loaded during linuxcnc startup, with the line
HALFILE=xhc-whb04b-6.hal
in the ini file. Everything for the mpg is in that file.

[andypugh]

I don't have access to an XHC device to test with. Are you able to build from source with the proposed changes and see if it helps?

[MetalMusings]

I opened this issue 1.5 years ago, so things might have changed since then.
I did some investigations 1.5 years ago. Disabling the assert()s helped. There were some situations where the module could reset/restart itself. But eventually it failed in libusb (I think). I tried to follow inside libusb but that was over my head and I concluded that is nothing I can fix. If I remember right it wasn't possible to unload the module, it got stuck and refused. Restart of linuxcnc helped and everything worked again.

I can compile and test, it will be a couple of days though before I can do that. I'll see if there is a mpg crash in the mean time and I will post the error message so it can be pinpointed.

[MetalMusings]

Here is a log of when the xhc-whb04b-6 locks up.

> debian@zx45:~/linuxcnc/configs/qtdragon45$ cat log.log
> LINUXCNC - 2.9.0-pre1-1132-g28b5b4174
> Machine configuration directory is '/home/debian/linuxcnc/configs/qtdragon45'
> Machine configuration file is 'zx45.ini'
> Starting LinuxCNC...
> linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
> Note: Using POSIX realtime
> Found file(REL): ./zx45.hal
> 
> Found file(REL): ./custom_pid.hal
> Found file(REL): ./custom_sinusM.hal
> Found file(REL): ./xhc-whb04b-6.hal
> task: main loop took 0.030574 seconds
> task: main loop took 0.018397 seconds
> task: main loop took 0.011172 seconds
> task: main loop took 0.030079 seconds
> task: main loop took 0.018816 seconds
> task: main loop took 0.011076 seconds
> task: main loop took 0.030254 seconds
> task: main loop took 0.018805 seconds
> task: main loop took 0.011240 seconds
> task: main loop took 0.029847 seconds
> transmission failed, try to reconnect ...
> transmission failed, try to reconnect ...
> libusb: debug [libusb_unref_device] destroy device 1.51
> debian@zx45:~/linuxcnc/configs/qtdragon45$

Four-axis milling machine. I had 200 kB worth of G-code displayed in the screen. Qtdragon low-res.
I tried to be in Aut mode and the turn the wheel on the mpg. I think the loop time comes from that point.
The failure happened when it was in MDI mode and I turned the wheel.
The error can be provoked in this way. I takes some tries though, often it works. Sometimes not.

The xhc-whb04b-6 module can now not be unloaded

> debian@zx45:~/linuxcnc/configs/qtdragon45$ halcmd show all | grep xhc
>     83  User  xhc-whb04b-6                                    184326 ready
> debian@zx45:~/linuxcnc/configs/qtdragon45$ halcmd unload xhc-whb04b-6
> debian@zx45:~/linuxcnc/configs/qtdragon45$ halcmd show all | grep xhc
>     83  User  xhc-whb04b-6                                    184326 ready
> debian@zx45:~/linuxcnc/configs/qtdragon45$ 

Link to error message

linuxcnc/src/hal/user_comps/xhc-whb04b-6/usb.cc

Line 235 in 620332f

if (r < 0)

[andypugh]

This doesn't look to be related to the "assert" lines?