Advanced Search

I wonder what "r" is - it doesn't say.
I'll some printouts.
One can possibly dig deeper into the layers and see exactly where it fails.
One level down:
github.com/libusb/libusb/blob/dcd30cec9a...ff/libusb/io.c#L1486

The crashing doesn't respond well to provocations. I can generally get it to crash when switching modes,
but it doesn't crash when I want it to crash.

Okay, thank you. I'm fairly certain that the reason for that message is that the pendant (dongle) has reset itself. But I don't think we know why it did so in this case. It could be something that the xhc-whb04b-6 component is doing wrong (different from the mode change delay). But it could also be that the dongle firmware is just that unstable.

I don't have any real good way to troubleshoot this. For the mode change timeout, I could capture the USB signals with a logic analyzer. But that is not feasible with my equipment if I need to wait for maybe one hour for the issue to occur. Wireshark is a possibility, but it does not show the low level packets...

I think the github issue is dead so better discuss here.

It's always the same error:github.com/LinuxCNC/linuxcnc/blob/ffc393...whb04b-6/usb.cc#L465
Don't have an actual log available, pretty sure it's that line

Yeah, at least for me the loops = 10 was not the solution to everything, so not surprised the situation is the same for you. As far as I have seen, this loops = 10 would only help during a LinuxCNC mode change (auto/manual/mdi/teleop/joint).

I was not aware of that issue, so that you for bringing that up. I will write a comment there (if I can), because I think what we have discussed here is a partial solution.

I would be interesting in knowing the error message (if any) when it fails, i.e. console ouput. This I can also "generate" myself, but right now I'm not using the machine.

Used the mpg today, sadly it crashed again. Loops = 10.

I actually opened an issue on github now over two years ago github.com/LinuxCNC/linuxcnc/issues/2237
No resolution. I never made a serious attempt to understand the code structure of the component.
Just looked at what was going on around the triggered assert() and made some more or less random changes.

Where is the blocking call? I'll see if I can do some ... tests.

Yes, I think its realistic to write a new firmware. The goal would be to have the pendant fully reliable and also proper detection if the RF link fails, possibly some other improvements as well.

It doesn't have to be an either/or solution. With the new firmware, I would probably strive to maintain "protocol compatibility", so the same xhc-whb04b-6 component could still be used.

Improving the xhc-whb04b-6 component is certainly possible, and hopefully that could be done as well. For this blocking wait state, I don't really see a clean/simple fix, other than reducing the max blocking time like we have done. And to be honest, the amount of abstractions used in the code makes it difficult to follow for myself.

But this is also one reason why I made this post. To see if others have similar issues (and now you have confirmed that its not only me). Maybe there is somebody else that wouldn't mind updating the xhc-whb04b-6 code, but would need inputs on what to change.

Is it realistic to write a new firmware for the dongle? Is it to improve on the reset?

Sounds like you identified blocking wait states as at least one big part of the problem.
Realistic to rewrite those sections in the component?

fyi, I have the radio version, works well for me needs.

I have loops set to 10 and timeout to 3.

Hi,
anhand deiner Hal denke ich, du sprichst deutsch.
Zunächst: Welche Vorlage hast du für die Konfiguration genommen?
In der ini sehe ich folgendes
1. Für die Verwendung des Handrades musst du noch die Makro buttons mit rein nehmen (müssen nicht belegt sein), sonst gibt es Fehler.
In die hal muss dann folgendes rein: loadusr -W xhc-whb04b-6 -HsfB

2. Es gibt keinen CIA402_HOMING_METHOD=-4 
Schau in die Dokumentation vom A6, da werden alle möglichen Homing Methoden aufgeführt.
Es gibt hier auch keinen Drehmomentbasierten Homing Modus. Du kannst aber einen Endschalter + Z-Impuls nutzen.
Der Endschalter muss aber dann am Driver angeschlossen werden (Di1;Di2)
Wäre zum Beispiel -1 oder -2 je nach Verfahrrichtung.
In der ethercat-conf.xml ist es empfehlenswert sync0Shift="0" zu setzen
 

Hopefully have a completely stable firmware and some type of watchdog to keep track of the communication. By the way, with firmware I speak about the USB dongle and with driver I mean the computer/LinuxCNC component.

I'm not completely happy with how the LinuxCNC xhc-whb04b-6 component works either. And at least for me, the amount of abstraction layers in that code makes it difficult to understand/change.

Ok, I continue with the 10 I have guessed and set.

Seeing that you understand pretty well what is going on, what will you do different with a new driver?

I believe I have 10, but can't verify until tomorrow or Monday. I have only tried the one value, which was an educated guess and seemed to work.

The total delay can be loops * timeout, i.e. 60 * 5 ms = 300 ms with the default values. In practice it can become longer because of how the delay is made and how the kernel schedules the task. I would imagine that as long as the delay is more than a few servo cycles, it should work. So probably it would work even with loops set to 1. But I have not tested. Nor do I think it would solve all issues that I experience.

What number do you use for loops? Is any number "best"?

Okay, thank you for the feedback. I realize now I wasn't clear in my last request, but I meant jogging with the pendant while a program is running. But you did that as well.

This setupAsyncTransfer() assertion failed is also what I had before changing the loops. That error occurs when the USB dongle has already reset, most likely because it saw no activity from the computer side.

I mentioned that after some time, the pendant still stops working for me. But I don't recall right now if I have even checked if I get the same setupAsyncTransfer failed at that time. I should check...

If you continue using this modified version, let us know if it looks to have cured the other issue you had as well.

I just started on writing a new firmware for the dongle. But I'm not sure where that will lead, if anywhere.

Tested today, but not very conclusive I'm afraid.

Default master branch.
Jog while running Gcode: Doesn't allow me.
First time running gcode, press stop. While in Auto mode spin the wheel: It crashes see screen dump below.
After restart and retry this several times: It works, it switches to Man and moves in Z.

With loops=10, it always works, at least the say five times I tried so maybe not conclusive.
I can continue with this setting to see if it fails later.
 
I always get this "assert" error when it fails.