Advanced Search

From what I understand, the immediate goal here is to get the A6 working reliably, and for that it makes a lot of sense to tailor the logic to what this specific drive exposes in 0x6040/0x6041. In that context, taking an SCL-style example and adapting it is a very pragmatic approach.

I also agree that the resync problem itself is exactly what homecomp is trying to solve. During internal CiA-402 homing the drive moves on its own, so LinuxCNC needs a way to keep pos_cmd in sync with pos_fb or to resynchronize cleanly afterwards to avoid the jump / E87.1. So the mechanism for handling this is already there.

Where I think we just need to be a bit careful (based on the docs and on what’s described in this thread) is mainly in the integration details:

1) The actual semantics of the homing bits.
Yes, 0x6040/0x6041 are standardized for the basic FSA, but in practice the homing-related bits are OMS / manufacturer-specific. Bosch uses 10/12/13 in a very clean and well-documented way, but Lichuan, for example, documents “origin found” on bit 15 and leaves 12/13 as “mode specific”. So for the A6, it probably makes sense to first confirm which bits really indicate “in progress / done / error” and then wire exactly those into homecomp.

2) When exactly the resync should happen.
homecomp provides the mechanism, but it still depends on being told when homing is active, when it is finished, and when it failed. If those signals come from bits that don’t quite match the drive’s real behavior, the resync may simply happen at the wrong time. So the key part here is just making sure the drive-specific semantics are mapped correctly.

3) Details like how “start homing” is triggered (pulse vs level, required preconditions, etc.) also tend to be drive-specific and are probably best verified on the A6 itself.

So I think we’re actually pretty close in approach: for the A6, observing the bits during a home run and adapting the logic accordingly sounds like the right next step. My only point is that the state machine itself is the easy part — the main work is just confirming the drive’s real homing semantics and hooking those cleanly into homecomp so everything stays consistent.

Did you try accessing it directly via its IP address?

Sometimes that works (but why?).

(Use bgp.he.net to find the IP address of any non-Cloudflared site)

glad you got it sorted out!

I have grown to like OpenBSD with its well thought through update commands and all.

Additionally, the absurdly high security makes using an outdated system less of an issue.

OpenBSD also comes with 3 (admittedly highly primitive) GUI options, which is a plus.

I managed to get the ./configure script to run with the attached script.

Due to a lack of thecommand on OpenBSD, I got AI to make a script to emulate it using (see attached file for details).

However, there are currently 4 issues:
1. Lack of tclx package (ostensibly a runtime dependency of LinuxCNC) on OpenBSD for some reason.
2. Lack of a libmodbus package on OpenBSD for some reason (functionality likely is reduced).
3.refuses to work.
4. No idea about realtime on OpenBSD.

BTW:
On OpenBSD,=

www.minimonster.ca

Tarts for allll!!!

It's been an entertaining and frustrating journey to get to finally be able to sell these machines. Thanks to everyone that helped me with all my linuxCNC needs.

Thought a bit about this with disconnects/reconnects.
It is actually normal behavior and the component is designed to work with that.
In run(), that is the main loop, github.com/LinuxCNC/linuxcnc/blob/ffc393.../xhc-whb04b6.cc#L414
There is a loop that opens the device, processes and teardown usb, repeatedly.

The stop in setupAsyncTransfer() should not be fatal. The assert() statement makes it fatal.
I now remember my original issue I opened two? years ago, it was to remove assert() statements,
because I at that time found that the code does the right thing, in principle. Just that the asserts() 
should be removed.

The call to setupAsyncTransfer tries to see if the usb device is connected with the mIsRunning flag,
but if I understand right (not necessarily) things change sometimes before libusb_submit_transfer().
github.com/LinuxCNC/linuxcnc/blob/ffc393...whb04b-6/usb.cc#L539
github.com/LinuxCNC/linuxcnc/blob/ffc393...whb04b-6/usb.cc#L456

I think now that the right thing to do is to have a failed libusb_submit_transfer() not crash the component through an assert() call
Instead finds it way in the call stack back to ::run() where the usb comm is torn down and the device is reconnected
and everything can continue.



 

Its hard to tell without a halscope plot that is scaled and timed so you can actually see the motion towards home

You might disable homing to index at least temporarily at that would simplify debugging

Are you sure there are no hardware connections that disable the drives when the home switch is reached?

Edit:

For HOME_FINAL_VELOCITY you might use  a low positive number since the PID is still not tuned

Also why are the X and Y limits covering a negative range? This is standard for Z but a bit odd for X and Y

I'm interested to try it out.

Can there be different versions of the usb dongle firmware?
Like newer devices don't have the reconnect issue?

Thanks for your support! I updated everything again today and now probe basic 0.6.5 ist installed and in the sim the toolsetter position is now there for X and Y. Will test with my router and real config next week.

Why does the Z-axis then work exactly as it should?
The limit switch slowly moves onto the cam. It receives the signal.
The limit switch slowly moves away from the cam and reports that the axis is referenced.

Which value do you recommend for HOME_FINAL_VELOCITY?

The commanded and fFB position are the correct ones to monitor

You might try rehoming after the first failed home so the actual motion towards home is visible
(uses a smaller scale)

I also note that HOME_FINAL_VELOCITY is 0 which as far as I can tell is not a legal value

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.