Advanced Search

Hmmm, the plot thickens. If I run the qtdragon interface,as in the config file I have uploaded, I get the following error. But if I switch the UI to axis in the ini file, no other change, it works...any ideas how that can be?

Hi Murphy
No but I will start my lathe project as soon as the mill is done. Was it you that posted a picture of the octocoupler bypass, I wanna try rigid tapping with the mill but I can't find the picture of the board modification. 

The stat-zero-speed comes directly from the drive, 12th bit of the statusword. 
No other processing is done. It seems there is some tolerance for zero.
Maybe your drive has some tolerance setting for this, mine didn't.

If the position is drifting in one direction I think you can check actual-velocity in hal
and switch modes when actual-velocity == 0.
Might combine this with oneshot component, so when actual-speed == 0,
you start oneshot to wait say 0.5 second before switching modes.
All done in hal at least when prototyping.
 

Thanks. Awesome. 6 pixels was all that was needed
 

 

Hello

I have a question. Which *.ngc files and variable entries do I need if I want to use a Rack ATC with LinuxCNC 2.9.7 and a Mesa 7i76e?

Regards,
Hilton

 

Colleagues, I installed kernel 5.4.258-rtai-amd64 + LinuxCNC 2.9.4 (kernel 290 too). In all cases, the AXIS interface is launched only when you specify additional kernel options such as isolcpus=1 (I have two cores), etc. But it starts and shows good jitter.
However, the actual work does not last long, but is interrupted due to a constantly appearing error -
joint 1 following error(motor number may change).

Is this treatable?

bin gerade am testen von smartserial auf esp32 und raspberry-pico, so als günstige IO erweiterung.

Ich hab die 7i92 auch schon bekommen, aber werde wohl erst in den Weihnachtsferien dazu kommen.
Dass kein Adapter auf den DB25 Port dabei ist habe ich zu spät mitbekommen, den muss ich mir noch besorgen.
Im der Krabbelkiste findet sich leider kein Flachbandkabel mit passendem Stecker..

I’m setting up automatic tool measurement on a 6-axis CNC mill using QtDragon with VersaProbe and running into calculation errors. The M6 remap executes successfully but produces incorrect/inconsistent tool offsets.
Machine Configuration:
    •    LinuxCNC 2.9.7
    •    GUI: QtDragon 1.4
    •    Interface: Mesa 7i96s Ethernet
    •    Axes: 6-axis (dual X gantry: X1, X2, Y, Z, A, B rotary)
    •    Tool change: Manual (no ATC)
    •    Fixed tool setter at machine coordinates X=397, Y=680, Z=-100mm
    •    Touch plate height: 41.54mm
    •    Actual physical tool length difference: ~22mm
What Works:
✓ M6 remap executes without hanging
✓ Machine moves to tool setter position correctly
✓ Probe successfully touches tool setter
✓ Returns to safe position
✓ tool-prepare-loopback HAL connection working
The Problem:
Tool offsets in the tool table are completely wrong and inconsistent:
Test Run 1:
    •    Tool 1: -29.113mm
    •    Tool 2: -7.077mm
    •    Difference: 22mm ✓ (correct!)
Test Run 2 (same tools, same setup):
    •    Tool 1: 0.070mm
    •    Tool 2: -22.105mm
    •    Difference: 22mm ✓ (correct!)
The relative difference is consistently correct (22mm), but the absolute values shift by 30-50mm between runs. Sometimes offsets are even positive when they should be negative.
My Workflow:
    1.    Home all axes
    2.    Clear all tool offsets (set Z to 0.0)
    3.    Jog tool to table surface, run G10 L20 P1 Z0 (set G54 Z=0)
    4.    Run T1 M6 - measures Tool 1
    5.    Run T2 M6 - measures Tool 2
    6.    Check tool table - offsets are wrongQuestions:
    1.    Should I be using G10 L1 (absolute) or G10 L10 (relative) for tool offset?
    2.    Is capturing #5420 before switching to G91 the correct way to get machine Z position?
    3.    After probing in G91 mode, is #5063 the incremental distance traveled, or does it contain machine coordinates?
    4.    Should the calculation be:
    •    probe_machine_z - probe_height (current), or
    •    tool_setter_Z - probe_machine_z + probe_height, or
    •    Something else entirely?
    1.    I’ve read that some people use Tool 99 as a reference probe - is that required, or should direct tool measurement work?
Related threads I’ve studied:
    •    forum.linuxcnc.org/40-subroutines-and-ngcgui/52490-remap-m6-tool-setter
    •    forum.linuxcnc.org/qtvcp/51138-qtdragonhd-tool-sensor-help-for-a-maker-space
Any help would be greatly appreciated! I can provide additional config files or testing results if needed.
5_axis.ini (VersaProbe section):
[VERSA_TOOLSETTER]
X = 397.000
Y = 680.000
Z = -100
Z_MAX_CLEAR = -50
MAXPROBE = 80

custom_postgui.hal:
net probe-in => qtdragon.led-probe
net tool-change      iocontrol.0.tool-change       => hal_manualtoolchange.change
net tool-changed     iocontrol.0.tool-changed      <= hal_manualtoolchange.changed
net tool-prep-number iocontrol.0.tool-prep-number  => hal_manualtoolchange.number
net tool-prepare-loopback   iocontrol.0.tool-prepare  =>  iocontrol.0.tool-prepared

qt_auto_probe_tool.ngc (key sections):
# Line 54: Clear offset before measurement
G10 L1 P#<tool> Z0

# Lines 56-57: Move to tool setter
G53 G0 X[#<_ini[VERSA_TOOLSETTER]X>] Y[#<_ini[VERSA_TOOLSETTER]Y>]
G53 G0 Z[#<_ini[VERSA_TOOLSETTER]Z>]

# Line 61: Capture starting Z (attempted fix)
#<start_machine_z> = #5420

# Line 63: Switch to incremental mode
G91

# Lines 64-71: First probe (fast)
G38.3 Z- #<_ini[VERSA_TOOLSETTER]MAXPROBE>
G0 Z #<_hal[qtversaprobe.backoffdist]>

# Lines 75-78: Second probe (slow)
G38.3 Z- [#<_hal[qtversaprobe.backoffdist]> *1.2]

# Lines 79-80: Calculate machine Z position
#<probe_distance> = #5063
#<probe_machine_z> = [#<start_machine_z> + #<probe_distance>]

# Line 82: Return to absolute mode
G90

# Line 88: Set tool offset (THIS IS WHERE THE PROBLEM IS)
G10 L1 P#<tool> Z[#<probe_machine_z> - #<_hal[qtversaprobe.probeheight]> + #<_hal[qtversaprobe.blockheight]>]

 

Thanks for the info, nice to see a Vendor have some proper support for Linux.

This is mini pc fujistu Q920
i disable about everything in the bios.
Still nothing
 
This is my current boot parameters with grub.Edit: I put linuxcnc on miniatx motherboard with intel i5 4460 and realtek RTL8168 ethernet.
 

Why did windows dominate the market?

The PC clone, which allowed many vendors to get in, sell at competitive prices and with PCs coming pre installed with Windows it was a no brainer. Old self proclaimed Dr\Farmer Gates was pretty aggressive.
TBH it took Linux a while to have a polished Desktop. A lot of misinfo about having to be a programmer to use Linux, mostly coming from a half generation that weren't aware MSDOS was command line only for many years. I think it's only us guys old enough to grow White Whiskers remembers early Linux and would have run it on a 486.
Until the wide spread adoption of the internet any security issues weren't exposed as they would be post internet, yes there were viruses around, but their source was either from physical media or BBS's.
As for Banks, most of the behind the scenes stuff would of been carried by ancient IBM systems, or Unix. My old ma remembers working in banks where one machine would take up a whole room (1970 or there about), living Down Under the aircon was great in summer.
They are quite a few local government locales in Europe & South America that have broke away from Windows.
The whole Third World Infrastructure is probably run by the West's Ewaste running pirated copies of XP, I don't think anyone is desperate enough to run Win2k unless it's a machine that has no connection to the outside world inside a Cold War bunker. Word has it that Win2k could catch the common cold from a user.

Betamax was superior to VHS, but VHS won out. The World's an imperfect place, I'm sure the Open BSD & Net BSD guys laugh at us Linux users. I wont talk to much about the Emacs \ Vi (Vim) flame wars, alot of good people perished.

unknown wrote:

Might be best to read the github page regarding some sites using warpinator.com domain.

#@$%!^%@&*
Dang it, i was not aware of that mess, so yeah
DO NOT USE THE WEBSITE warpinator dot com
Use GitHUB
For Linux it is

Ah, bummer, sorry to hear that, hopefully it's repairable! Keep us posted!

I'm sorry to say that I have to pause my efforts on this chapter with elliptical faults. As I tried yesterday to get new corrected lines in my Hal and INI to try out what helps (the day before yesterday, I tried to change the Y axis to stepgen.03 what did'nt work, I did'nt change wires but changed the plugs from stepgen.01 to stepgen.03) and I found that stepgen.01 was dead. I changed then stepgen.01 to stepgen.02 and motor-01 was working correctly.
So, I have to send my MESA card to a friend to repair the burned stepgen chip, this will last several days.
Meanwhile, I will consider if I could change to my free 7i96S, the problem there will be spindle settings and several other things to adapt.