Advanced Search

Search Results (Searched for: )

  • RotarySMP
  • RotarySMP's Avatar
Today 15:07
Replied by RotarySMP on topic Retrofitting a 1986 Maho MH400E

Retrofitting a 1986 Maho MH400E

Category: Milling Machines

That shifting into neutral also annoyed me. That was corrected. Take a look in the github for some revision he did. That made it stay in gear.

Not sure way you mean by F9 engaging low first gear?
  • Tserakhau
  • Tserakhau
Today 14:47
Replied by Tserakhau on topic Retrofitting a 1986 Maho MH400E

Retrofitting a 1986 Maho MH400E

Category: Milling Machines

Hello
I figured out the center positions (muted them in the HAL, combining them with the middle position).
All gears shift perfectly!!!
The only thing I can't figure out is why F9 always engages first gear
and after the spindle stops (with any stop command), the transmission shifts to neutral. Is this how it should be, or have I messed up something in the HAL?
  • spumco
  • spumco
Today 14:05

Considering a Full Rewire on a Working Schaublin 125 CNC

Category: Turning

G96 D2500 ? 2500 m/min surface speed? Cutting steel with carbide  is typically only 1/10 that or less.
Maybe consider G97 S500 just to remove a variable while you are getting used it it?


 


"D" is max spindle speed, not desired surface speed.
  • cmorley
  • cmorley
Today 13:29
Replied by cmorley on topic Using Offsetpage Widget?

Using Offsetpage Widget?

Category: GladeVCP

As I expected, it's because offsetpage does not automatically find the var file.
You must make a handler file to set the var file  path.

Something like this (it assumes the offset widget is called 'offsetpage' and the var file is called 'sim.var')
import os

varpath = os.path.join(os.getcwd(),'sim.var')

def get_handlers(halcomp,builder,useropts):
    return [HandlerClass(halcomp,builder,useropts)]

class HandlerClass:
    def __init__(self, halcomp,builder,useropts):
        obj = builder.get_object('offsetpage')
        obj.set_filename(varpath)
        obj.set_col_visible("abcuvw", False)

  • BIBIGUL
  • BIBIGUL
Today 13:17 - Today 13:31

Remora - ethernet NVEM / EC300 / EC500 cnc board

Category: Computers and Hardware

"tuxcnc" I feel like when I calling Microsoft customer's support... "We dont know what is your problem, but it works with us..." I know how Linuxcnc does the threading, and know why it is acceptable with LPT and not acceptable with devices using ethernet link. LPT uses base_thread, ethernet uses servo_thread, so LPT can be ten times faster. I told you few posts ago, the servo_thread=1000000 (1 ms period) can make delay that can produce 18 degrees positon error at spindle rotates 3000 rpm. 3000 rpm => 50 rps => 20 ms per revolution. It is mathematics, everyone can make this calculations. The solution is not send the extended index in hope the Linuxcnc see it, and resets position to zero when received it. The solution is send raw_count latched at every real encoder's index edge. We can restore encoder's index (if we need) from (old != new) at the component. And we can reset position not to zero, but to real position captured at index edge. We can be confused, because we use "index" word for different meanings (encoder's output, program variable, hal pin) but we can not change this. Detailed explanation: Let's assume the encoder's index edge occurs at 1000 raw_counts. Time goes, counter counts A/B signals. The component requests data. At this moment raw_counts is 1050. We send both values, counted and latched. The component knows, the index was 50 counts ago and sets position to 50/scale not to zero. (of course only when hal index_enable pin is set) What don't you understand?

You're thinking along the right lines, and this can definitely be improved.
Interrupts break determinism and can introduce jitter into the system. The jitter might be small, but it's still there because the core has to stop processing, handle the ISR, and then resume the program.
We need to get rid of interrupts entirely for this.
Configure the timer like this:

 TIM4->SMCR = (TIM_SMCR_SMS_0 | TIM_SMCR_SMS_1);     // ENCODER MODE (TI1 & TI2)
 TIM4->DIER = 0;                                     // NO INTERRUPTS
 TIM4->CCMR1 = (TIM_CCMR1_CC1S_0 |                   // (CH-A) CC1S = 01 (TI1FP1 --> TI1). CH1
             TIM_CCMR1_IC1F |            // F SAMPLING.                        CH1
             TIM_CCMR1_CC2S_0 |          // (CH-B) CC2S = 01 (TI2FP2 --> TI2). CH2
             TIM_CCMR1_IC2F);            // F SAMPLING.                        CH2

 TIM4->CCMR2 = (TIM_CCMR2_CC3S_0 |                   // (CH-Z) CC3S = 01 (TI2FP3 --> TI3). CH3
             TIM_CCMR2_IC3F);            // F SAMPLING.                        CH3

 TIM4->CCER |= TIM_CCER_CC3E;                        // Capture/Compare enable CH3
 TIM4->PSC = 0;                                      // PRESCALER = 0
 TIM4->ARR = 0xFFFF;                                 // 65535


 The timer will operate as an encoder counter (Channels 1 & 2) and **simultaneously** Channel 3 will be configured for **Input Capture mode**. The Index pulse (Z-channel) is connected to Channel 3.

 **What do we get from this?**
 *   `TIM4->CNT`: The current raw encoder count.
 *   `TIM4->CCR3`: The **exact hardware state** of `CNT` latched at the moment of the rising or falling edge of the Index pulse.

 This gives us an extremely accurate hardware snapshot of the counter at the exact moment the index pulse occurs.

 **Next Steps:**
 We just need to extend the communication protocol and send both `CNT` and `CCR3` for each encoder.
 Then, on the **LinuxCNC side**, `CCR3` should be processed similarly to how the Mesa driver handles `CNT`.

 When Motion sets `index_enable` in the driver, we simply do:

 if(CCR3 != CCR3_prev) {
     // HURRAY, THIS IS THE TRUE INDEX!
    // Now we can correct the raw counter based on the current CCR3 value.
 }


Result: We get precise index homing without needing to send an `index_enable` request down to the STM32. Everything is handled cleanly on the LinuxCNC side.

 Hope that makes sense.
  • andrax
  • andrax's Avatar
Today 12:30
Tuning Steperonline A6 Servos was created by andrax

Tuning Steperonline A6 Servos

Category: EtherCAT

Hi,

I have a general question about tuning the Stepperonline A6 servos. 
I set up the servos using the auto-tuning feature.
I’m quite happy with the results.
However, I’ve noticed—especially when probing in the range of 0.01 mm and 0.001 mm—that the servos respond very imprecisely. I’d like to make them more precise.

How did you handle this?

I’d also use Stepperonline, but I can’t get a connection to the servos with it. 
 
  • endian
  • endian's Avatar
Today 11:49 - Today 11:54
Replied by endian on topic Ethercat random jitter fix

Ethercat random jitter fix

Category: EtherCAT

So I am not really qualified here but I've had some ideas which I explored.The Core Issues

  • Version 1.5.2 vs. Modern Branches: The reason version 1.5.2 felt "smoother" is because it often operated in Free Run mode. It wasn't strictly enforcing nanosecond-precise timing, so it never performed the violent corrections ("snaps") seen in newer, more precise versions.
    • The "Startup Snap": Grandixximo’s branch is designed to solve Phase Drift (especially common at a 1ms servo thread). To get the PC and the network in phase, the driver forces a massive time jump (the 1.6s jump Hakan lists) at startup.
      • Cheap Hardware Sensitivity: Modern, lower-cost EtherCAT servos have lower-quality internal clocks and smaller "sync windows." Unlike premium hardware, they cannot "soak up" timing errors and will grind or stutter the moment the Master clock shifts

        Deployment Fixes
        1. Slave 0 Hierarchy: The first DC-capable device in the chain is the Reference Clock. For industrial stability, this should always be a high-quality device (like a Beckhoff EK1100) rather than a budget drive.
          • The "Machine On" Interlock: You should never enable the machine (allow physical motion) until the system is "in range." The drives should be kept in a disabled state while the driver performs its initial 1.6s "snap" Hakan shows
The "Safe Window" Logic: Implement a HAL interlock that monitors the
pll_err pin.

Hold the enable signals low until the error is stable (maybe for a few seconds) Yes, some AI input here but this is a summary of a detailed conversation I had with my well trained assistant 

I think its very weird now ... I remeber that times when everybody here are running deb10 with 4.19 kernels and 1.5.2 master version... there was no timing problem at all either at startup of lcnc... I single grinding from the Kollmorgen S300 drivers at 1ms single time but I solved it by installing native driver and editing the assignActivate of DC from 0x0300 to 0x730 and every grinding sound was gone ... that drivers are pretty sensitive DC stuff really same to AX5000 from beckhoff(I do not know if I go right that time ... ) I am running well tunned i5 with around 2us latency beckhoff IPC but startup delay are present nowdays... sometime even AX5000 drivers are not became OP because of this synchronization issue I think ... somewhere there is the original thread of lcec from sascha and there is really really really recommended to start the physical ebus with the DC capable device, best practise is one of the axis  I can not see under the hood of lcec because its not my cup of tea but, it should be real breakthrough it this tailchasing will be done
  • andrax
  • andrax's Avatar
Today 11:34
Replied by andrax on topic Probleme mit G Code...

Probleme mit G Code...

Category: General LinuxCNC Questions

Läuft den der Code ohne T... M6 bzw. Fräserdurchmesser 0?
 
  • LeoWa
  • LeoWa
Today 11:30
Yukon Drive was created by LeoWa

Yukon Drive

Category: General LinuxCNC Questions

Hello,

I'm planning to build a 5-axis machine. For the rotary axis, I intend to use a harmonic drive servo, driven by a Yukon Drive 1021 AFO.

LinuxCNC seems like a good choice for this project, but I'm wondering if it's possible to control the Yukon Drive using a Mesa card with +- 10 V analog output (I was considering a 7i92+7i77 setup).

Has anyone done something similar, or can confirm if this setup will work? Are there any issues I should be aware of?

I look forward to your replies.
  • rodw
  • rodw's Avatar
Today 11:09
Replied by rodw on topic Ethercat random jitter fix

Ethercat random jitter fix

Category: EtherCAT

So I am not really qualified here but I've had some ideas which I explored.The Core Issues
  • Version 1.5.2 vs. Modern Branches: The reason version 1.5.2 felt "smoother" is because it often operated in Free Run mode. It wasn't strictly enforcing nanosecond-precise timing, so it never performed the violent corrections ("snaps") seen in newer, more precise versions.
  • The "Startup Snap": Grandixximo’s branch is designed to solve Phase Drift (especially common at a 1ms servo thread). To get the PC and the network in phase, the driver forces a massive time jump (the 1.6s jump Hakan lists) at startup.
  • Cheap Hardware Sensitivity: Modern, lower-cost EtherCAT servos have lower-quality internal clocks and smaller "sync windows." Unlike premium hardware, they cannot "soak up" timing errors and will grind or stutter the moment the Master clock shifts

    Deployment Fixes
  1. Slave 0 Hierarchy: The first DC-capable device in the chain is the Reference Clock. For industrial stability, this should always be a high-quality device (like a Beckhoff EK1100) rather than a budget drive.
  2. The "Machine On" Interlock: You should never enable the machine (allow physical motion) until the system is "in range." The drives should be kept in a disabled state while the driver performs its initial 1.6s "snap" Hakan shows
  3. The "Safe Window" Logic: Implement a HAL interlock that monitors the
    pll_err
    pin. Hold the enable signals low until the error is stable (maybe for a few seconds)
Yes, some AI input here but this is a summary of a detailed conversation I had with my well trained assistant
  • Pudding1960
  • Pudding1960
Today 10:23
Replied by Pudding1960 on topic Probleme mit G Code...

Probleme mit G Code...

Category: General LinuxCNC Questions

Danke für die Mühe ! Aber das Problem taucht auch auf,wenn ich einen G-Code lade,der gestern noch Funktioniert hat,aber heute nicht mehr. Gestern habe ich einen Relativ Simplen G Code gestartet mit einer Kontur und 3 Bohrungen. Ein Teil ging Problemlos zu Fräsen,beim 2. Teil nach dem neuen Antasten auf Y fingen die Probleme an. Am Dispay sieht es so aus,als ob der Bohrer genau an der richtigen Position eintaucht,die Maschine fährt aber an die ursprüngliche Position ... Alle Nullpunkte stimmen aber ! Oft hilft dann Herunterfahren,neu Starten,Referenzfahrt und von Vorne beginnen. Aber diesmal kam wieder die Fehlermeldung mit den Kreisbogen.. Seit 4 Jahren benutze ich Fusion 360 (Leider) und Linuxcnc. Linuxcnc habe ich noch die Version von 2021 unverändert am Steuerrechner Installiert,ohne Update ect. Lief bis vor 1 Jahr eigentlich ohne Probleme. Leider bin ich was G-Code und Linux angeht nicht gerade ein Experte. Für mich ist die Fräse eigentlich nur Mittel zum Zweck und sollte mich daher nicht Zeit zur Fehlersuche Kosten. Komme ohnehin viel zu wenig zum Arbeiten damit.
  • tar_san
  • tar_san
Today 10:06

Proper value for FERROR ? (EtherCAT Servo)

Category: EtherCAT

I want to trigger an error if the difference between the actual servo position and the commanded position exceeds a certain threshold (e.g., 5mm) due to external forces. However, unless I set the
FERROR,MIN_FERROR
 in the .ini file JOINT section to something very large (like 50 or 500), a 'Following Error' occurs immediately.

= INI FILE =[JOINT_0]
MIN_FERROR = 500
FERROR = 50

I want to set these values to be able to check following error within 5mm (5.0mm)
 I have already tuned the SERVO gains appropriately and confirmed that the actual physical deviation is nowhere near 50mm. The servo's electronic gear is configured so that 1 unit equals 1/1000mm, and I am converting the values to integers before writing them to EtherCAT.

= HAL FILE =
setp cia402.0.pos-scale 1000
 I know threre are 1ms time difference in EtherCAT and latency for servo position, but I think these settings are not proper.

Which part of LCNC settings should I check or modify to resolve this problem?

 
  • tar_san
  • tar_san
Today 09:39
Replied by tar_san on topic Ethercat, CIA402, Yaskawa Sigma-X

Ethercat, CIA402, Yaskawa Sigma-X

Category: EtherCAT

I'm using Sigma-X with EtherCAT.
I could rebuild IgH Master, thanks to Hakan.
Yaskawa Sigma-X is very strict for communication timing, etc.
  • papagno-source
  • papagno-source
Today 09:26
Replied by papagno-source on topic Ethercat random jitter fix

Ethercat random jitter fix

Category: EtherCAT

Good morning everyone. This is very likely the problem. I've noticed that sometimes the problem occurs on the first reboot. I start LinuxCNC, with automatic startup at system startup. If I restart LinuxCNC with the system running, the problem goes away, but sometimes it doesn't. Tomorrow I'll try to test Grandixximo's latest fix. If it doesn't work, I'll reverse the bus sequence, install the SLA and I/O last, make sure the drives are the first node, and modify HAL.
  • Hakan
  • Hakan
Today 08:50
Replied by Hakan on topic Ethercat random jitter fix

Ethercat random jitter fix

Category: EtherCAT

I seems the initial delay is caused by lcec setting a bad initial reference time to the slaves.
Here is a listing of the first five lines, from lcec.write-all.
Data is cycle number, pll-err, reference clock time, application time
0 0 3536553781 142022168
1 0 3536553781 143094900
2 1629533556 2808528640 144063093
3 0 2809491813 2810488578
4 10994 2810477584 2811488510
lcec reads reference time of 3.53 second, and then sets it to 2.80 seconds. (lower 32 bits).
Now, speculating a bit, the clock is not changed right away, instead the clock is slowly changed
and the slave maintains a system time offset register 0x92c. It can then report and accurate
time by using the clock, that is off until in sync, and add the system time offset.
Must say it is speculation this though.

Anyway, the initial time setting in rt_app_main, or possibly the first few rounds in lcec_write should be looked at.
 
Displaying 1 - 15 out of 285335 results.
Time to create page: 2.442 seconds
Powered by Kunena Forum