Advanced Search

1. gcode
2. hal
3. GUI's
4. hardware

Dear friends, honored to be member of the community , as a new migrant from Mach3 i raelly shocked of the level of profissionality and experience and i admit " i regret about the long years i was afraid to join LinuxCNC " , I ask the profissionals to create a roadmap to help of generating new generation of experts to the community, from a to z :
- the programming skills needed.
- the CNC basic and advanced knowledge .
- linuxcnc, system terminology and construction.
this is a basic idea and i hope our superiors and expert to descuss this issue and sure this is a great investement in the future   

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.