Advanced Search

Thanks for taking a swing at that. One thing we can all agree on is that the manual is dogshit
Feeding dogshit into AI seems to result in a similar result as when I used to mow over the dried up dog turds on the lawn when I was a kid.

This is an old 8214. Specifically EVF81214-E
 
The VFD doesn't have a built in brake chopper. There are two options, either a "Brake module" with an integrated resister, or a "Brake chopper" which feeds an external resister.
 

 

I first bought the external resister due to lack of understanding / research.
 

 
.. .before I worked out it does not connect directly to the VFD.

Then I bought the "Brake module" EMB 8252-E, which connects to the UG+ and UG - pins.
adegis.com/media/asset/6e4b8a95789dbed2a...ed149b4af51f912d.pdf
They are connected correctly.

However, that is not the issue. If you look in that video I linked a couple of message further above, at that point in the video, you can see the VFD oscillating back and forth into overcurrent as it tries to brake the spindle motor, without any form of resister added.

Back then, I somehow found out how to set the VFD into a coast down mode.  That must have happed just after I made that video.

When I  hit the spindle stop, the VFD switches straight to "off", and current drops to zero, no attempt at decelleration, no over current. That is how I operated it for the last couple of years. 

Before I even connected the brake module, I tried to return the VFD from "coast down" mode to normal brake (which would mean overcurrent without the brake module installed), and failed.

I can see two explanations.
1/ I was informed of, or stumbled onto a parameter setting, or combination of them to set the VFD to coast down. So it no longer follows the C13 deceleration setting, it just disconnects from the motor, and leaves it to coast down. Now I can't find that setting, nor remember what I did.

2/ I blew something in that VFD which was responsible for decelleration current. But there are no other symtoms of anything blown in this drive. It works perfectly, and gives no errors.
Cheers,
Mark


 

Hello Hakan

can i had 2 instances Cia402

Cia402dBraun for xyz and cia402pv for spindle? did you know that?

Teste mal sowas hier: de.aliexpress.com/item/1005009918532948.html
Wäre interessant zu wissen, ob sowas plug & play ist, oder ob man Firmware o.Ä. braucht.
Bei dem Preis lohnt es sich jedenfalls nicht Arbeit und Zeit in ESP32 zu investieren.

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.