Advanced Search

Good Day CnC's

I am a "TOTAL" new bee to Linux and to LinuxCnC trying to get the new Ver. 10 to run with the help of AI and maybe 5-6 hours installing on my  Zorin 18.1 Linux computer.
I managed to get it installed only to get an terminating error on opening the program it says to create a report file which i did but can not find the report and don't know how to send it to someone if i did find it. so I seem to need some help if some one can provide some guidance
here is a cut and paste of the error. it will not be hooked to any machine at this time. Just would like to get the program to run for right now

Tks if anyone would like to tackle this. if not I'll understand.

5280 (ken)


Print file information:
RUN_IN_PLACE=yes
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/home/ken/linuxcnc-dev/bin
LINUXCNC_TCL_DIR=/home/ken/linuxcnc-dev/tcl
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/home/ken/linuxcnc-dev/rtlib
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/home/ken/linuxcnc-dev/src/objects
INIVAR=inivar
HALCMD=halcmd 
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.10.0~pre1
Machine configuration directory is '/home/ken/linuxcnc-dev/configs/by_machine/cooltool'
Machine configuration file is 'Basic540_3axes.ini'
INIFILE=/home/ken/linuxcnc-dev/configs/by_machine/cooltool/Basic540_3axes.ini
VERSION=1.1
PARAMETER_FILE=stepper.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=
HALBRIDGE=
DISPLAY=axis
COORDINATES=X Y Z
KINEMATICS=trivkins
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Can't execute server program linuxcncsvr
Shutting down and cleaning up LinuxCNC...
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Stopping realtime threads
Unloading hal components
rtapi_app: exit received while not running

I don't see anything in 'facing.ngc' that could cause a simultaneous move in X and Z.

Could you put a debug message inside of your 'facing.ngc' and run that macro again. Just to be sure that that is the actual file being executed (You should see a info message popup in the gmoccap gui).

Something like adding '(MSG, Executing facing.ngc)' to the start of the sub:

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