Advanced Search

Naja, den Rpi5 kannste ja trotzdem brauchen, war ja kein rausgeschmissenes Geld, aber weg vom Parallel-Port ist das einzig richtige und dann noch für kleines Geld

@UI
Oh, das ist ja mega interessant mit den Karten aus China, da hoffe ich sehr auf deinen Bericht


Gruß
Olli

I'm glad you got something working for you. I am testing code for future ability to set resolution.

Chris

[SOLVED] XHC-WHB04B-6 on LinuxCNC 2.9.6 (QtDragonHD + 7i96S) — Beginner notes
(I am sharing the exact steps I followed, written simply. Many threads assume advanced users; I am a beginner.)My machine / system

• Gantry router XYYZ (dual Y motors), work area approx. 1300 x 1210 mm
• Controller: Mesa 7i96S (Ethernet, step/dir)
• Spindle: 2.2 kW, 24,000 RPM
• UI: QtVCP / QtDragon_HD
• OS: Raspberry Pi 5, Debian 12 (Bookworm)
• LinuxCNC 2.9.6

What actually fixed it (short version)

1. Load the pendant HAL file as a HALFILE (before the post-GUI), same as the donor machine.
2. Add MDI_COMMAND lines under [HALUI] so pins halui.mdi-command-XX exist.
3. Keep qtvcp_postgui.hal clean (only GUI signals, no pendant driver).
4. In my case, moving the WHB USB dongle to another port made the wheel/jog and DRO updates work.

STEP 1 — Copy the pendant HAL file
Place xhc-whb04b-6.hal in your config folder (the same folder that has your .ini and main .hal), e.g.:STEP 2 — Load the pendant before the post-GUI
Open your .ini and in the [HAL] section add this line and keep this exact order:Important: do not load the WHB driver inside qtvcp_postgui.hal.STEP 3 — Create MDI pins under [HALUI]
In the same .ini, find (or create) the [HALUI] section and paste this block right under it:This creates halui.mdi-command-00..07 (indexes follow the order above).
Add more MDI_COMMAND lines if your xhc-whb04b-6.hal uses higher indices.Notes so jogging actually works

• E-STOP released, Machine ON
• Manual mode
• Fully homed (for XYYZ: X, Y1, Y2, Z)
• On the pendant, use Continuous, or Step + Step size
• If the wheel does nothing or DRO does not update: try a different USB port/dongle (this was the final fix for me)

Thanks and request
Many thanks to the original thread’s author for sharing files and guidance.
If possible, could you post a short summary of the final button mapping (what each macro-N does, Continuous/Step, ABS/REL, etc.)? That would help beginners keep their configs consistent.If anyone needs it, I can share my final .ini, xhc-whb04b-6.hal, and a minimal qtvcp_postgui.hal exactly as they ended up.

10 in/sec is well beyond what we ever need; indeed, I'd be surprised if we need to achieve even 0.1 in/sec.  That was just an attempt to see if changing that value would drive the needed speed.

As for commenting out the PID stuff, that was due to the way I understood them to be only needed for servo motors, and not for stepper motors.  This is based on my reading of section 2.13.2. Servos in the manual (linuxcnc.org/docs/stable/html/config/ini...ub:ini:sec:joint-num).

Quite probably, I misunderstood the manual.

I will add the PID stuff back into the configuration and test tomorrow, and then report back.

After looking at the schematics and hal file I realized there is an error on one or the other but the estop pin I needed to get the machine to release was on tb2 rather than tb3 that the drawing indicates. I connected that so it is "bypassing" the non existent estop switch and bobs your uncle I can get the ui out of estop and mess around with pin outs and what not. I plan on editing the program quite a bit more to move all of the user controls to the 7i73 that will be mounted in the user interface box rather than running all the wires back to the main 7i77 in the electrical enclosure. I verified connectivity with the 7i73 so it should be fairly smooth sailing from here(crossing my fingers) I have ordered as many different breakout boards/connectors so I don't have to splice into the existing wiring. My goal is to have as minimal invasivity if that's a word as possible. In theory being totally reversible with no retermination of connectors. It added a bunch of extra cost but I think it is way more valuable having all the connections in tact and original.

ok here are my files and the reference file for the mh400e which was made about 5 or more years ago I think. I made a bunch of configs so I am sorry the name is the default I need to change it. again I think this is mostly working now short of a few bugs I need to test some things out and move towards wiring things to the mill

Can you create a small Python file (as simple as possible) that when I call it via REMAP = M6 modalgroup=6 python=remap_m6 , for example, only moves the Z-axis by 10mm

Just to follow on from Rod's comment.

Many of the UIs that are visually modern/graphical expect a 1080p display.  For example ProbeBasic imust have 1080p or larger.  The upside is a lot on a single screen at once. The more "original" or "old school" UIs expact much less with a 720p display being very roomy for them.

Re the comments on starting with Axis.  I would second that approach VERY strongly.   You will save youself a huge amount of potential frustration by having a working machine under Axis as your baseline.  That way when moving to another UI and you have issues you can better pin point where things are falling down when you KNOW you have a working Axis config.

Yes, 8mm/turn = 3.175 turns per inch so ~1900 RPM at 10 IPS
which is at the edge of stepper capability (at least with usable torque)

Perhaps the OP does not know that the hal/ini velocity settings are
in machine units (inch in this case)  per second rather the minute
 

this is my new test file remap_m6:

#!/usr/bin/env python3
from interpreter import INTERP_OK, INTERP_EXECUTE_FINISH, INTERP_ERROR

print(">>> remap_m6.py wird geladen <<<")

def remap_m6(self, **words):
try:
tool_number = words.get('t', 1)
print(f">>> M6 Werkzeugwechsel aufgerufen: T{tool_number} <<<")
# Sofort fertig melden
yield INTERP_EXECUTE_FINISH
except Exception as e:
print("Fehler in remap_m6:", e)
yield INTERP_ERROR

yield INTERP_OK

But this is supposedly not executable?

'remap_m6' is not a Python callable function - 49:REMAP = M6 modalgroup=6 python=remap_m6

I've already made some Python scripts that work, so why is it so different when called with M6?

If I calculate it right, that's >15m/min

I think it's not possible to reach this speed with steppers

The PID setup is missing key values so I would not think you would get
any motion, for example X:

#****************************
# AXIS X JOINT 0 CHANNEL 02
#****************************
setp pid.x.FF1 1
setp pid.x.Pgain 1000
setp pid.x.error-previous-target true
setp pid.x.maxerror 0.000500
net x-index-enable => pid.x.index-enable
net x-enable => pid.x.enable
net x-pos-cmd => pid.x.command
net x-pos-fb => pid.x.feedback
net x-output <= pid.x.output

 

Always get your machine working fully on axis first, then consider converting to a more modern interface. With say qrdragon, there are quite a lott of additional pins to connect to the GUI to enable every feature but you need to be confident the basics (from axis) are working... Be aware of screen size  limitations. I had to buy another monitor for QTD...

These are the files.  The .INC files were renamed to be .INI so that they could be attached.

I've attached one spindle file:  that one and the one for Spindle1 all work exactly as expected.

I also attached only two of the axis files:  U & Y (due to the file limit).

Can you post your complete hal/ini files, or al least the joint sections of both?