Advanced Search

Thanks for the replies. The spindle.0.revs seems to be right when turning by hand, and when driving with the VFD active it is hard to tell exactly, but it seems to be correct as well.

Trying in constant speed instead of surface speed is a good idea, I will try that next.

And regarding diameter and radius, the man page I even linked says:

Note: When G7 Lathe Diameter Mode is in force, the values for I, J, and K are diameter measurements. When G8 Lathe Radius Mode is in force, the values for I, J, and K are radius measurements.

I don’t know how I overlooked that, it is really obvious now.

I set up front and back angles, but it needed diameter to start displaying the inset shape.

However... it's displaying the tool tip past centerline when the tool is at X0.  I tried fiddling with the table angles (-87 & -32 vs 342.5 & 287.5) and it didn't make a difference.

Same display issue when the WCS rotation is in effect.

Below photos has tool #2 active.

 

Having looked at this a few times, I think that the best place to do it is actually in a G-code filter. ie calculate the heading from the G-code and insert / append C axis moves as appropriate.

I am surprised that you have tool cones and not lathe tool shapes in the graphics. You should have a reasonably accurate picture of an insert.
You may need to set up frontangle and backangle in the LinuxCNC tool table for that to work, as well as the orientation.

The manual mentions "analog setpoint" and that this is +/-10V DC.
So, I think you probably can.

f-error calculations compare joint.N.motor-pos-cmd and joint.N.motor-pos-fb.

Maybe you are not scaling the -fb value before passing it back to LinuxCNC (or, possibly, the scaling is taking place in the wrong slot in the servo thread)

Tested F360's' "turn below center" feature and it seems to work quite well with the standard LCNC post.

Example:

• Tool is a 'back' tool, but on my backtool-defined lathe the tool is pointing away from the operator (up).
• Tool defined in F360 as 'normal' orientation, i.e. tip down.  F360 defaults to a slant-bed turret lathe, so X+ is up in the simulation.
• Tool set to 'turret 104' for post 'gang-tool on X+ turret'

OP1 OD turning looks good:

 


OP2 ID turning, with 'turn in negative X' enabled:

 

Tool is set in the LCNC tool table with orientation as T2 (earlier post), so the backplot looks like reality with the WCS rotation M-code.

It seems like this workflow and post means I don't have to set up different tools in the same library for multi-function ID/OD tools.  Nice.
 

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?

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?

RotarySMP wrote:

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.

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')

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- 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.

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. 
 

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

Läuft den der Code ohne T... M6 bzw. Fräserdurchmesser 0?