Advanced Search

Hi Andy,
Sorry for the slow response. I dropped the ball on this as I was doing wood working .

This is the facing.ngc file I am using. I have not modified it at all. I just noticed I have both a "lathemacro.ini" and a "lathemacros.ini" (plural) in my machine directory. Could that be the issue?
Cheers,
Mark

Most UIs allow you to adjust the view direction.

linuxcnc.org/docs/html/gui/qtvcp-widgets...idgets:gcodegraphics

Seems to suggest using the _view property in the handler code.

I have a good model of my lathe, but the mill model is rather lacking.
There are a few milling machine models on Thingiverse / Printables etc.

grandixximo wrote:

github.com/mika4128/liscio/tree/main
new trajectory/gcode compressor for the future trajectory planner, testers wanted, feed your gcode to it, check the SVG output
 
Hi grandixximo and mika4128 (Yang Yang),
Curve smoothing is the correct and best way to tackle Jerk that is normal to the motion path. This is reflected in the curve smoothing features from the large CNC controller brands referenced in the Liscio documentation.
I put the liscio library through an AI based analysis for integration into linuxcnc.
This is the analysis it has come up with.

Let me know how we can progress on this topic and the eventual jerk limitation implementation.

-automata

 

Library facts (verified in source, not the README):
- 6 `.c` files + 1 internal header + 1 public header; MIT licensed, single author (Yang Yang
  `This email address is being protected from spambots. You need JavaScript enabled to view it.` — the same upstream author as the already-vendored `cruckig`).

- Exactly one `calloc` (create) and one `free` (destroy); zero allocation afterward. No printf/assert/
  globals in library paths. Context is ~148 KB (91% of it a 64-slot arc-merge buffer); fitter stack
  worst case ~25–30 KB (bounded recursion, depth 8).

- `liscio_pose_t` is layout-identical to `EmcPose` — nine consecutive doubles x,y,z,a,b,c,u,v,w
  ([emcpos.h:19-23](../src/emc/nml_intf/emcpos.h), liscio.h:44-50). Add a `static_assert(sizeof)` in the
  adapter as cheap insurance.

- Emit is a synchronous callback invoked inside `add_*`/`flush` calls.### Known library defects and gaps (must be addressed before starting integration)| # | Defect | Evidence (liscio clone) |
|---|---|---|
| L1 | `liscio_reset()` does not clear `arc_buf_n` — arcs buffered before an abort are emitted into the **next program** | src/liscio.c:1437-1444 |

| L2 | No runtime tolerance setter — cfg is copied at `liscio_create`; G64 P/Q changes mid-program have no cheap path | src/liscio.c:108-131, liscio.h:285-309 |

| L3 | XYZ-collinear LINE fast path skips the ABC/UVW linearity gate — interior rotary nonlinearity silently discarded | src/liscio.c:540-561 |

| L4 | No `isnan`/`isfinite` anywhere; tolerance gates are `if (dev > tol)` so **NaN passes** | grep of src/ |

| L5 | F-word changes are absorbed silently (first-F-wins, plus an off-by-one via the flush reseed) | src/liscio.c:669-676, 1302-1311 |

| L6 | `liscio_emit_stop(pos=NULL)` emits zero poses despite header docs claiming last-known-position | src/liscio.c:1402-1407 vs liscio.h:363-367 |

| L7 | `liscio_add_arc` validates nothing (unit normal, radius/center consistency, type field) — caller trust | src/liscio.c:1181-1239 |

| L8 | Corner/discontinuity detection is XYZ-only — pure-rotary reversals never split the window | src/liscio.c:687-709, 736-752 |

| L9 | Struct doc mentions a `turn` field that does not exist (direction+wrap live in signed `arc_angle`) | liscio.h:98-105 |

| L10 | Independent verifier (`test_verify`) and fuzzer are XYZ-only / add_line-only — 9D fidelity is not regression-gated upstream | test/test_verify.c:53-62, test/test_fuzz.c |

L1 and L3 are correctness bugs; L2 is a hard integration blocker; the rest are adapter obligations.

The original bearings are 6209 2RS and 6009 2RS; they don't have "C3" stamped on them, so they are likely CN (standard clearance). They are press-fitted without any additional clamping.

You only need C3 if the bearing is an interference fit in the housing and on the shaft.
What are the original bearings? If they are C3 it will say on them.

Open a halmeter and see what the mode flags show:
linuxcnc.org/docs/stable/html/gui/halui.html#_mode

mode.is-manual needs to be true for jogging to work, it seems possible that something is changing mode.

Are you keyboard jogging, or using handwheels? It might just be a UI focus problem, with the key presses being "captured" by the button itself.

But check the mode first.

You ought to be able to update straight to 2.9.10 now that you have a working install.

What interfaces / motors does the current setup use? Is it a stepper machine or servos?

If it's a simple stepper machine you could make a start using the hal_gpio module and Pi GPIO pins, but you will need some level-shifting protection as the existing logic is almost cetainly 5V (or 24V) rather than the 3.3V of the Pi GPIO pins.

Are you planning to retain the existing drives?
I tink that where you choose to make the cut between old and new would depend on where the electronics failures are happening.
But it is generally best to keep the original motors and often (but by no means always) best to keep the original motor drivers.

Doesn't the 4000L have the carriage handwheel MPGs? I would think that those make a pendant superflous.

forum.linuxcnc.org/10-advanced-configura...oling?start=0#225787

forum.linuxcnc.org/show-your-stuff/53476...rical-mapping#307444

Any progress so far? I was wondering, if the mathematics in @nojo project is correct, would it be possible to create a hybrid solution by combining it with @fsabbatini project? Specifically, using the tool offset handling from @fsabbatini project and integrating it into @nojo project.

I'd like to thank everyone who contributed to making this project a reality. Fantastic work! The difference with the new S-curve planner enabled is huge. Motion is noticeably smoother, and the overall machine behavior has improved significantly.

Here is the file, you can see that  stepgen 03  has only dir , I don't understand why I put aside this combination: 7i80-7i85s-7i37 went 3 motors in step dir. I only need it as a transition because then I will switch to the 7i97t in analog, but for now I wanted to use step dir for 4 motors without any encoder or anything else.
in practice only the stepgen 3 one doesn't work 

Actually one way to do this would be to write a gcode filter for linuxCNC  that looked for hole below a certain diameter, removed the hole processing and replace it with a spot at the hole centre. Monokrom plasma has a filter that modifies hole processing so perhaps it can help you.

Another really out there possible solution that does not need post processing (but requires master branch) could  be to write a component or modify plasmac.comp and monitor the pin motion.interp.iscircle. When it goes true and motion.interp.arc-radius < minimum hole radius, disable the torch, use external offsets to move a distance of motion.interp.arc-radius along motion.interp.normal-heading (which will be your hole centre), fire the torch to spot, then unwind the offsets to return to where the torch was, let motion take over again then enable the torch when iscircle goes false.(the end of the hole)

QtPlasmaC should have a hole spotting/pierce only feature, i am pretty sure i tested that a while back.
www.google.com/search?q=qtplasmac+pierce...tplasmac+pierce+only