Advanced Search

Another error after trying to "sudo apt upgrade".

Error: Failed to fetch www.linuxcnc.org/dists/trixie/2.9-uspace...pace_2.9.9_amd64.deb  404  Not Found [IP: 69.163.143.134 443]
Error: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

Why is that happening?

The good thing is that I managed to install the ethercat. But I used another computer with UEFI for the purpose.

Thank you very much in advance!

 

Sascha wrote:

Check the encoder resolution in the software. Mine were advertised as 24-bit and there are 23-bit. I have the L8EC drive and ACM2 motors.

Thanks, this is indeed true, they are 23 bit optical. 

Sounds like a great little project, keep up the good work and keep us posted.

Sure thing, take a look here:

forum.linuxcnc.org/plasma-laser/58942-fa...ing-scanning-project

Thanks!
Jeff

I have been working on a small LinuxCNC companion project called **FabScan**. The basic idea is to create a LinuxCNC-friendly camera tracing utility that can help capture outlines, edges, holes, and reference points from real-world parts, then export usable DXF geometry for cleanup/CAM.

The project was inspired by the general workflow of SheetCam Scanything, to be clear it is not based on Scanything code, reverse engineering, or proprietary information. It is a from-scratch MIT open-source project aimed at LinuxCNC users.
The project can be found here: github.com/FabLabRacing/FabScan
The documentation is lacking at this point, it is mostly build notes.

The intended workflow is:

1. Mount a USB camera on the Z-Axis.
2. Use LinuxCNC for the actual machine position reference.
3. Use FabScan to view the camera, detect edges/lines, capture points, and build geometry.
4. Export DXF.
5. Use SheetCam or another CAM program for cleanup, tooling, and cutting.

## Current Status

The current working milestone is around **v0.5.10**.

At this point, FabScan can:

* Load an image and detect contours.
* Adjust threshold, blur, minimum area, and simplify settings.
* Select/classify/sort detected contours.
* Export DXF geometry.
* Capture from a USB camera.
* Rotate/flip camera view as needed.
* Calibrate camera scale.
* Capture manual points from LinuxCNC position.
* Continue native DXF geometry using lines, arcs, and circles.
* Perform controlled X/Y motion through LinuxCNC.
* Jog X/Y from inside the app when enabled.
* Use camera center-dot calibration.
* Preview line/edge detection from the live camera.
* Take single-step and multi-step line/edge following moves.
* Export traced/captured geometry to DXF.

The newest work has been focused on camera robustness and line/edge following.

The line-following proof of concept is working well enough to be useful in testing. One important recent improvement was latching the follow direction during multi-step tracing. Before that, the detected edge tangent could occasionally flip direction and cause the machine to step backward. The current logic uses the selected Forward/Reverse direction for the first move, then chooses the next tangent direction closest to the previous successful move. In testing, this fixed the forward/backward flip.

A recent test captured 50 points along a Sharpie line without the direction flipping. The average step was about 0.050", with the largest observed deviation roughly in the .006"-.009" range. That was with the line slightly out of square with machine travel, so I was pretty happy with the result for an early proof of concept.

## Safety Philosophy

FabScan is intentionally limited.

It only moves X and Y.

It does not control:

* Z axis
* Torch firing
* Plasma start
* Cycle start
* Spindle
* Cutting output
* THC
* Any actual machining/cutting process

LinuxCNC still owns the machine. FabScan only talks to LinuxCNC for position/status and controlled X/Y motion. Motion functions require LinuxCNC to be in a safe state, such as machine on, homed, idle, and in manual mode.

The idea is that FabScan should behave more like a camera-assisted measuring/tracing pendant than a machine controller.

## Hardware / Test Setup

My current known-good test setup is:

* Dell OptiPlex 7060
* LinuxCNC / QtPlasmaC
* Mesa Ethernet hardware
* USB microscope/camera
* Camera resolution currently set to 800x600
* LinuxCNC servo period set to 2,000,000 ns

One important lesson from testing: my microscope camera does not support 1280x720. Asking for that resolution caused OpenCV/V4L2 timeouts and made the GUI sluggish. The current version defaults to 800x600 and is being improved to handle unsupported camera modes more gracefully.

## Recent v0.5.10 Camera Work

The latest camera robustness work includes:

* Default camera resolution changed to 800x600.
* Resolution presets added.
* Requested vs actual camera resolution display.
* Explicit V4L2 camera opening on Linux.
* MJPG request where supported.
* Camera frame reads moved off the Tkinter UI thread.
* Better handling of bad camera devices or unsupported modes.
* Safer preview window close handling.


## Current Line / Edge Follow Settings

The current settings that seem reasonable for testing are approximately:

* Mode: line center
* Step: 0.050"
* Max correction: 0.010" to 0.015"
* Minimum confidence: 55-60
* Count: 10-50
* Camera: 800x600

For tight curves or 180-degree bends, the plan is to reduce step size and search area, while keeping correction conservative.

A future safety improvement I am considering is stopping multi-step follow automatically if the heading changes too much in one step, maybe somewhere around 60-75 degrees. That would help prevent the trace from trying to chase a wrong edge or doubling back unexpectedly.

## What It Is Useful For

The project is aimed at things like:

* Tracing a physical part or cardboard template on the table.
* Picking up edges or holes from an existing part.
* Capturing a rough outline for SheetCam cleanup.
* Following a drawn Sharpie/scribe line.
* Getting usable geometry from shop-floor parts without turning the project into a full CAD system.

## Project Direction

The near-term direction is:

1. Keep improving camera reliability.
2. Make camera selection/resolution handling more user friendly.
3. Improve line/edge following confidence and stop conditions.
4. Continue improving DXF export quality.
5. Keep the project focused and safe.

Long term, I would like FabScan to become a practical open-source tracing/scanning helper for LinuxCNC users, especially for plasma/router-style machines where a camera-assisted part tracing workflow can save time.

It is still experimental, but it has reached the point where the core idea is working and the project feels worth continuing.

Thanks for the update! We'd love to see how things are looking now. Maybe you could share a short video or a screen recording someday.

all the best

tom
 

Hi all,

another short update on LatheEasyStep:

I continued working on the embedded QtVCP startup behavior and focused on the panel initialization path.

On my machine, the startup time with the panel embedded in LinuxCNC was reduced from about 49 seconds down to about 11 seconds.

The main work was cleaning up the widget lookup/initialization path, removing expensive startup overhead, and limiting panel-related searches strictly to the panel itself instead of doing broader lookups.

The panel is now usable again immediately after startup on my system, which is a big improvement compared to the previous state.

I will continue cleaning up the code step by step, but this was an important milestone because the panel is now much more practical to use in everyday work.

Regards

Anybody need ?

I trying to hook up with a guy in an unfriendly timezone (for an Aussie) who has been working on a implementation of the MTconnect protocol for Linuxcnc that does exactly what you want. The cool thing is that it supports MQTT and there are already integrations to Home Assistant if you have a Fanuc machine.  Right now, I don't know any more detail but keep an eye on my @MrRodW YouTube channel as I will cover it there. Once we get going, I'm sure another like minded helper won't go astray. 

Pushed.
I don't immediately see how to split the update of screen vrs plot points or whether that would make much difference. Lets see what the world thinks of your changes.

. I have been working on a small project I call FabScan, which uses a USB camera mounted to the machine to help trace parts/templates and eventually export geometry. That type of experimentation is much easier on an open PC/LinuxCNC system than it would be on a closed standalone controller such as MASSO.

Can you tell us more about this in another thread?

hi I know its been a while for this post, but I'm wondering if this makes sense for, essentially moving U and V with X and Y commands.

The Fix:
How to make UV emulate XY while keeping their own step calibrations.
To force U and V to mirror X and Y while preserving their independent step calibrations, you must link the signals before the math calculates the motor steps.
In LinuxCNC, you do this by linking the motion controller outputs to both sets of joints, rather than linking the step generators directly.
Open your machine's main .hal file and look for the lines connecting motion.coordinate-system to your joints. Change them to route like this
:hal# Force Joint 2 (U) to listen to the X-axis motion command
net x-output motion.coordinate-system.0.pos-cmd => joint.0.motor-pos-cmd joint.2.motor-pos-cmd

# Force Joint 3 (V) to listen to the Y-axis motion command
net y-output motion.coordinate-system.1.pos-cmd => joint.1.motor-pos-cmd joint.3.motor-pos-cmd
Use code with caution.Why this fixes the calibration issue:
The Signal: LinuxCNC outputs a raw request in millimeters (e.g., "Move X to 50.0mm").The Split: The HAL lines above take that 50.0mm request and send it to both Joint 0 (X) and Joint 2 (U) simultaneously.The Calibration: Joint 0 looks at its own SCALE setting in the .ini file to convert 50.0mm into steps for the X motor. Joint 2 looks at its own independent SCALE setting in the .ini file to convert 50.0mm into steps for the U motor.

This is particular is quite weird:

hm2_7i90: selected address 0x8100

Not really sure whats going on

Does the port at 0x378 work as a normal parallel port?
 

I've seen a couple of "solutions" to this, but my question here is: what's the canonical way to detect that linuxcnc is shutting down and/or exiting, or isn't running, using the python linuxcnc.stat.poll() api ?  I can start my python script in hal using loadusr, but there's no unloadusr, and I can't just run it at computer boot because linuxcnc.stat() just fails if linuxcnc isn't running yet.  I tried using the parent PID but that isn't reliable (and prevents you from manually running the script in the background)
I've attached my script.  I'd like to cleanly detect that linuxcnc has exited or the computer is shutting down, and send a final MQTT message to home assistant to update the status to "off".
 

Print file information:
RUN_IN_PLACE=no
LINUXCNC_DIR=
LINUXCNC_BIN_DIR=/usr/bin
LINUXCNC_TCL_DIR=/usr/lib/tcltk/linuxcnc
LINUXCNC_SCRIPT_DIR=
LINUXCNC_RTLIB_DIR=/usr/lib/linuxcnc/modules
LINUXCNC_CONFIG_DIR=
LINUXCNC_LANG_DIR=/usr/lib/tcltk/linuxcnc/msgs
INIVAR=inivar
HALCMD=halcmd
LINUXCNC_EMCSH=/usr/bin/wish8.6
LINUXCNC - 2.9.9
Machine configuration directory is '/home/cnc/linuxcnc/configs/Cnc_xyz'
Machine configuration file is 'Cnc_xyz.ini'
INIFILE=/home/cnc/linuxcnc/configs/Cnc_xyz/Cnc_xyz.ini
VERSION=1.1
PARAMETER_FILE=linuxcnc.var
TPMOD=
HOMEMOD=
TASK=milltask
HALUI=halui
DISPLAY=qtvcp qtdragon
COORDINATES=XYZ
KINEMATICS=trivkins coordinates=XYZ
Starting LinuxCNC...
Starting LinuxCNC server program: linuxcncsvr
Loading Real Time OS, RTAPI, and HAL_LIB modules
Starting LinuxCNC IO program: io
Starting HAL User Interface program: halui
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod
Found file(REL): ./Cnc_xyz.hal
Shutting down and cleaning up LinuxCNC...
Running HAL shutdown script
hm2: loading Mesa HostMot2 driver version 0.15
hm2_7i90: loading HostMot2 Mesa 7i90 driver version 0.3
hm2_7i90: wrote control 0x04
hm2_7i90: read status 0xFE
hm2_7i90: selected address 0x00
hm2_7i90: read data 0xFF
hm2: no firmware specified in config modparam!  the board had better have firmware configured already, or this won't work
hm2/hm2_7i90.0: Low Level init 0.15
hm2_7i90: selected address 0x8100
hm2_7i90: read data 0xFFFFFFFF
hm2_7i90: read status 0xFE
hm2: unloading
Removing HAL_LIB, RTAPI, and Real Time OS modules
Removing NML shared memory segments

Debug file information:
Note: Using POSIX realtime
hm2/hm2_7i90.0: invalid cookie, got 0xFFFFFFFF, expected 0x55AACAFE
hm2/hm2_7i90.0: FPGA failed to initialize, or unexpected firmware?
hm2_7i90.0: board at (ioaddr=0x0378, ioaddr_hi=0x0778, epp_wide ON) not found!
hm2_7i90: rtapi_app_main: Invalid argument (-22)
./Cnc_xyz.hal:9: waitpid failed /usr/bin/rtapi_app hm2_7i90
./Cnc_xyz.hal:9: /usr/bin/rtapi_app exited without becoming ready
./Cnc_xyz.hal:9: insmod for hm2_7i90 failed, returned -1
1645
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

these are the files and the response