Advanced Search

Which kind of IndraDrive do you use?

some of them are SoE ... And it has have to startup IDNs 

If you need EoE for something else at ethercat you can edit eeprom at drive... but I can recommend you to reisntall ethercat master with eoe disabling... it way easier path...

I tested now and get same behavior as you. This was some small news for me. I thought it only started reconnecting if it had already been in use already by LinuxCNC.

The test was like:
1. Pendant off, plug dongle into computer. No disconnects for 5 minutes.
2. Turn pendant on. Disconnects start with around 20 s cycle.
3. Turn pendant off. It looks like dongle stays disconnected. Maybe just bad/good luck with the timing.

I already made some first steps for a new driver. The initial target of that was to have reliable polling. I already abandoned it and started thinking more about the firmware. But maybe I should give it another shot. I'll try to have a look tomorrow if I can clean it up just slightly and post it here. It's simple enough to play around with and it should be able to provide stable polling.

The HAL and INI files are on page 6.
I can upload the HAL and INI files again tomorrow evening, but there are no changes in that area. Have I selected the correct channels for logging?

Ismacr63 wrote:

I’ve tried changing the field names in Turning using Qt Designer so they match the macros, but without success. I’m not exactly sure if what I tried makes any sense, since I don’t have experience with this.I’ve looked at the files in the link, but are they for Probe Basic Mill? This is a bit beyond me because I don’t really have the necessary knowledge…I also saw a post on the Facebook page about an update to the lathe conversational section. Does anyone know when that update will be released?

it will be a while and that is not a "probe basic" item it is actually a universal machine conversational that will also be able to be added in as an external plugin to probe basic. its a ways out as i have limited time to work on it lately.
 

dont change the ui names, modify the macros otherwise on an update you will be overwritten while macros in your config folder for machine are not

If you just have the dongle and pendant attached and switched on do you get resets every 20 sec?
I mean, without linuxcnc.

I took the dongle and pendant to a bit newer N150 PC. Plugged it in. Ok, was discovered.
Switched on the pendant and it started with the 20 sec disconnects/reconnects.
Switched off the pendant with the button and it stopped. There is a clear relation.
It can be related to polling, I guess.
Searched for a simple program to regularly poll a usb device.
Best I found was "usbreset" but it didn't change anything.

Interesting that you MRx says it is stable. Advice was to test with USB 2.0 and I have looked
and it isn't easy to find a PCI-E USB 2.0 board I can get in a few days. My motherboard
Gigabyte Z170N-WIFI does have an internal header for USB 2.0/1.1 and I should get a cable
and test I guess.

Unfortunately neither plot shows any motion so it hard to tell what's going on.

Can you post your current hal/ini files?

Hello everyone,

Today I recorded data from the Z-axis, which is functioning correctly, and then I tested the X-axis.

The X-axis limit switch moves onto the cam and then simply stops instead of moving freely.
After a few seconds, the following error message appears: joint 0 following error

I’ve tried changing the field names in Turning using Qt Designer so they match the macros, but without success. I’m not exactly sure if what I tried makes any sense, since I don’t have experience with this.I’ve looked at the files in the link, but are they for Probe Basic Mill? This is a bit beyond me because I don’t really have the necessary knowledge…I also saw a post on the Facebook page about an update to the lathe conversational section. Does anyone know when that update will be released?

You are awesome! Thank you very much!

 

I had/have very similar issues as you mention earlier today Hakan. The after the pendant disconnected once, it kept doing so every 20 s or so, just like for you. And you see the LIBUSB_ERROR_NO_DEVICE because the dongle has disconnected. However, if you again start LinuxCNC (maybe need to try a couple of times to get the timing right), the pendant will resume working just fine and the disconnects stop for the time being.

As I have said, I believe the reason for the disconnects is that the dongle is unhappy with the current situation and resets itself. And "unhappy with the current situation" is most likely because the host has not been polling its interrupt endpoint for some time (maybe half a second or so).

I attach here a logic analyser screenshot, capture file as well as wireshark capture from a "forced" disconnect event. For this capture, I had the dongle disconnected, LinuxCNC (sim) running a program and in the background waiting for the pendant. I then started all captures, connected the pendant, pressed the Step button (and maybe some others) on the pendant and jogged the wheel. This caused the Usb::setupAsyncTransfer assert failed.

In the screenshot you can see that from approximately 2950 ms (corresponding to wheel jogging), there are no packets until ~3600 ms (except for SOF, which I have turned off on purpose). And at 3750 ms, there is a reset on the USB bus, corresponding to the dongle "disconnecting" and the assert failed. This reset is as far as I'm concerned generated by the dongle itself, because it was unhappy with the conditions.
 

If I zoom in a little bit on the disconnect/reset event, that becomes more clear. Here I have turned the SOF packets back on, and we see that they are sent every 1 ms as expected. And then suddenly the D+ signal drops to zero, indicating a bus reset (either from the device or the host). And I see no reason why the host should generate a reset in this situation, so I say its generated by the dongle. This is consistent with repeated disconnects every 20 s already discussed.
 

The .sr file can be opened with PulseView and the .pcapng with Wireshark, in case anybody wants to have a look.

At least for me the pendant is anything but solid. And I do think the dongle firmware is mainly to blame. That being said, it could very well be that different drivers/hardware could mask some of the issues I experience. If only I knew what causes (all) the disconnects, I'm sure we could figure out some ways to fix it.

Hi, I will be retrofitting two Prototrak machines (TRL1440 LX2 Lathe, DPM5 SMX Mill) that use the Servos, Glass Scale Encoders, and Digital Handwheels with Disk Encoders and am thinking that I will require the 7i77 and 7i89 to process the Servo and Encoder Breakouts. I currently have a 6i25 from a previous build, hence the desire for the 6i25 + 7i77 + 7i89 firmware build.

Thank you so much!
Mike

Under normal operation there's no disconnect of the XHC pendant. It's solid. If you power it off it will disconnect.

I heard from others that they had EMI problems with USB and the XHC pendant in the past, I'm going to operate it with a large CNC in the near future so I will see if it will hit me too.
I think you have to fix a problem on the USB layer, maybe use another system which has a native USB 2.0/ehci port. The XHCI USB ports can cause issues depending on the hardware.

By the way you can easily convert an WHB04B to 6 axis by removing a stopper with a knife which is inside the rotary switch. 6 axis are wired up even on the 4 axis versions.

I have an idea.
rodw: Can you make the bits from 0x6041 available as pins?
Then we can observe the bits during the home run.
If we know which bit is set when, the state machine could be set up accordingly.
But maybe we're overcomplicating things.
I took a look this afternoon and looked at various CIA drives. 0x6040 and 0x6041 are standardized. All CIA402-compatible drives use the same bits. 
See here:
Bosh Rexroth CIA Status word

That means all we really need to do is find a suitable SCL code from Beckhoff or Siemens and rewrite it for Linuxcnc. For example, this one: