Advanced Search

Good morning, I bought an xhc-hb04 because mine had fallen and the wheel didn't turn well, but it still works. When the new one arrived, I immediately noticed that it stays on even when the PC is off, which the old one didn't. It's detected because if I remove the LinuxCNC dongle, it gives me an error. The working one has a chrome power button, while the new one has a plastic button. I think it's defective. What do you think?

No, I did not really start a rewrite. I made a small program to communicate with the pendant, but it was more for troubleshooting than planned as the start of a new component. But I did make a new firmware for the dongle, which I have been using without issues so far.

Maybe it was not completely fair to compare it to the xhc-hb04 component. Anyway, I'm glad somebody made this component in the first place, and of course all your bugfixes and improvements are a clear step in the right direction.

I experienced an issue with arc preview just a few weeks ago that I made a post about. I think this may be a bug or limitation in the preview only rather than connected to the issue you mention. But I thought I might as well mention it, since it has some similarities to the issue you mention.
forum.linuxcnc.org/20-g-code/58285-stran...r-circular-arc-g2-g3

@Finngineering: So you did not start a rewrite? I see it the same way. The actual component looks like a school book example of object oriented design, then it didn't suite the needs, took way more time then estimated and the needed redesign, simplification and finalizing never happened. But for a rewrite, the chances are high the same will happen and to get it to the functional state the actual module has, it will take a lot of time. So if it works now, fine. If there emerge unsolvable issues, we can think about it again.

I looked quickly into the xhc-hb04: is way less complex but it also has less functionality. I find this automatic change to manual quite nice. And the xhc-hb04 has a complex hal and config file which probably also makes it difficult to use.

@rodw: As I understand linuxcnc, before homing, you can only jog single axis due to the kinematics needs homing. But due to jogging Y1 separate from Y2 will bend the gantry, this is deactivated like in my machine using HOME_SEQUENCE. I don't need jogging before homing, so that's fine for me.
However, the WHB04B tries to activate jogging also before homing and then generating errors. For me, that's a non-issue, I just don't touch the wheel. And if it happens by accident, nothing else happens except an error messages.
For non-gantry machines, you can jog also before homing, so I did not remove that functionality because it might be useful for others.
An solution would be to add a command line option for this. However, I rather create some chips than continue coding...

Additionally, I started another rabbit hole which is more important for my machine:
github.com/LinuxCNC/linuxcnc/issues/3839

Just a note: Linuxcnc is just a hobby for me I started recently. But I have a lot of experience in coding and bug fixing from my day job and I figured fixing the issues I am having myself and creating PR's would give something back to the community.

I think there is an oversight in the homing model. I can't see why joint axes can't move in unison before they are homed. If my first machine didn't have a gantry, maybe I'd have a different view. I've often wondered why this treats each side or a gantry as seperate axes when they are always joined at the hip!

There are always situations with tool and work piece geometries
and unfortunate stop situations where one need to stick the nose (eyes) close up
to guide the tool out of the situation before it's free for homing.
I guess the best is to leave it up to the user if he wants to jog before homing.

Hakan wrote:

Get a real machine, rodw
In a milling machine and lathe, there are many situations where you may need to jog before homing.
To get the tool out of the way before homing for example.
 

I had a mill and am building another. I thought HOME_SEQUENCE was designed to get the tool out of the road 

Get a real machine, rodw
In a milling machine and lathe, there are many situations where you may need to jog before homing.
To get the tool out of the way before homing for example.

 

Hannes wrote:

@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

In this case its far better to disable motion before homing with a simple change to the ini file. I still have no idea why people want to move or jog before homing. None of my machines allow this! And yes, one was a XYYZ gantry plasma table that jogged with a pendant perfectly!

Tested the latest changes, and everything works as expected. Thank you!

Yeah. I also grepped for usleep at one point, but didn't really bother trying to figure out if it will cause issues elsewhere. If you go back to some of the first posts, you see I also considered writing a completely new component. Part of the reason for that was to have a state model and avoid these blocking sleep calls. The other part was that I think that the level of abstractions used is bordering on ridiculous for the application. The xhc-hb04.cc component has one order of magnitude less lines of code and does more or less the same thing. But now that you are fixing things, and with my own firmware, I personally don't see a need for a completely new component at this time.

Thanks for testing!

There might also have been a bug in libusb. This kind of error handling is always difficult to test when you don't have errors.

I did not go that deep into USB. But your explanation sounds reasonable. I changed it to interrupt. It did not make a difference for me but rather correct than wrong but still working, I pushed a new commit. Feel free to test if you did not test that anyway already.

Note: There are also other usleep() in hal.cc. So they might also give issues. However, fixing that is a lot of effort. I thing it's easier to write it new from scratch using parts of the existing code. But if it works now, that's fine anyway...

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.