Advanced Search

I have a few questions regarding the Remora ETH source code. I understand it's built on the lwIP stack.

Does lwIP significantly impact the servo cycle timing? Does it cause noticeable lag/jitter?

Has anyone attempted to implement their own custom stack with Zero-Copy support? I suspect this would yield a decent performance improvement.

How is the time domain problem solved between the PC's servo cycle and the STM32's time domain? Or does the system simply operate in a fast response mode — processing commands immediately upon arrival from the PC?

If the time domain mismatch isn't handled properly, you simply cannot achieve precise velocity and acceleration control, especially when dealing with position feedback from the encoder.

Thanks.

andypugh wrote:

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.

One way I guess, but how does the gcode continually update the heading on a G2 or G3 as it traverses the arc? I found this had to  be done in motion. This will work, I just got taken over by other priorities which are now subsiding.

I'm struggling to launch a gladevcp panel from my gmoccapy interface. I've queried the web for examples and feel that I'm on the right track, but without success.  I'm open to any suggestions.

I've attached my .ini file along with my gladevcp.ui and custom_postgui.hal for reference.

FYI - I have a laser crosshair that I use to locate the program start for a project. The laser can be toggled by either the gladevcp panel or via a toggle switch on the machine. I've wired up the machine such that either source will set an input pin high to turn on the panel LED. If the laser is toggled via the machine toggle, I want a visual indicator to remind me to turn it off manually.
Once I get the panel to display and the led to toggle properly, I may split the input to I get a visual indicating which source toggled the LED, but for now I just want to get the panel up and working. There is no custom python handler needed at this time.

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.