Advanced Search

Depends how you define "basic". My paid-for Fusion costs me something like $400 a year and that includes indexed / wrapped 4th axis which allows me to do things like splines and gears. True simultaneous 4th axis requires the ruinously expensive manufacturing extension. That's always been a disappointment that rather limits the use of my 4th axis.

Exactly our point. For the same cost as a one year Fusion subscription of their basic CAD and CAM, you get Takshak for life which has an even larger rotary operations library than Fusion. If you buy it before 30th September, you get it at half that cost.

Anyone saying 200 USD is too expensive for that capability sounds rich enough to pay 1500 USD per year to Fusion and I have no beef with them. 

No you got us wrong. The license has a launch offer of 199 USD. That offer is for 30 days from launch and ends on 30th September.

Post that the launch offer ceases and anyone buying from 1st October onwards pays 399 USD.

If you bought it before 30th September, its your forever at 199.

Irrespective of whether you bought it for 199 before the offer expires or 399 after it expires, you still get 30 days of usage to decide if you want to keep it. If you dont like it, you can ask for a refund.

You can add multiple rules, use the right click rules dialog and add as you need, you can also add multiple channels to use in the expression. The expression can have multiple else continuation for each test to display.  There are examples in the ui, take a look at some of the labels and there rules.

Lcvette wrote:

Then you should not need any python code use just rules
 

This is what you meant when you mentioned the if/then/else rule statement earlier, right?  That gets me the three color states for the stopped/running/paused indicator.

To get the three text values, I'd need a second if/then/else rule for the widget... or the same status channel rule can do both appearance and text displayed?

A follow-up on **FabScan**, the LinuxCNC camera tracing/digitizing project I posted about earlier.

FabScan has now reached:

**v0.6.0-alpha.1**

Project:
github.com/FabLabRacing/FabScan

I am definitely not calling it finished, but I think it has crossed an important enough milestone to call it an alpha and, more importantly, to start asking the open-source community for help improving it.

## What Changed

The biggest change since my original post is the tracing architecture.

The earlier versions were basically:

detect local line
→ calculate correction
→ move
→ repeat

That worked surprisingly well on simple geometry, but corners eventually exposed the limits of that approach. I spent quite a while developing various versions of "Corner Assist", but eventually concluded that I was trying to solve an architectural problem with more special-case logic.

The current v0.6 approach is closer to:

Camera / perception
        ↓
Persistent world-space path belief
        ↓
Connected-path prediction / look-ahead
        ↓
Planner
        ↓
Controller / safety
        ↓
LinuxCNC motion

The design principle that came out of that work is:

**Detectors observe. The model remembers. The planner decides. Motion executes.**

FabScan now tries to understand and follow the connected continuation of the profile rather than simply reacting to the latest local line fit.

## Record/Replay and Simulator

A fairly substantial development framework grew out of trying to debug the follower.

FabScan can now record complete physical tracing runs, including camera frames, calibration, planner state, motion, and diagnostics, then replay those runs deterministically.

Replay was extremely useful, but it has one unavoidable limitation: once a new planner chooses a different path than the old one, there are no recorded camera frames from that new location.

That led to an SVG ground-truth simulator using the exact A-G test geometry.

The simulator runs the real FabScan perception, estimator, and planner against a virtual camera that can move wherever the planner chooses. It also includes measured camera appearance, observation delay, and the actual configured motion limits from my LinuxCNC table.

That has become one of the most useful development tools in the project.

## Latest Real-Machine Result

The current hardest test geometry is shape **G**, which contains straight sections, tabs, a 45-degree corner, a radius, and several sharp direction changes.

The latest physical run completed:

**800 / 800 planner steps with no HOLD**

It stopped only because Count was set to 800, about **0.738" short of completing the loop**.

Some comparison numbers:

M5.6 simulator full path:    21.5182"
M6.2 physical implied path:  21.5091"

Physical RMS error vs SVG:   ~0.00446"
87.6% of path within:        0.005"
96.4% of path within:        0.010"

LinuxCNC itself followed the requested coordinated XY endpoints very closely, with an average endpoint miss of about **0.00045"**.

The remaining larger errors are concentrated around a few sharp vertices where the planner begins turning slightly early.

That is encouraging because the problem is becoming very specific rather than looking like general path instability.

## Where Help Would Be Useful

The biggest current planner question is how best to distinguish:

**continuous curvature / a radius**

from:

**a true sharp connected-path vertex**

For a radius, normal look-ahead following should continue.

For a true corner, I think the planner needs to recognize it, commit to the actual vertex, finish the incoming leg, then latch onto the outgoing leg.

Other areas where ideas or contributions would be welcome include:

* state estimation / Kalman-style approaches
* connected-path association and branch scoring
* confidence models
* machine vision
* diagnostics
* eventual continuous/velocity-based following
* LinuxCNC integration

## HISTORY.md

I added a `HISTORY.md` file to the repository specifically for anyone interested in the development side of the project.

It is a bit longer than the normal documentation, but I think it is worthwhile reading before digging into the planner because it explains **why the current architecture exists**.

It covers:

* the original local follower
* the Corner Assist experiments and why that approach was abandoned
* the move to persistent path state
* why record/replay was added
* why replay eventually led to the simulator
* what the simulator is intended to prove
* what the first physical tests exposed
* the A-G test geometry
* simulation vs real-machine results
* the major open design questions

There is also a condensed decision tree showing how one development problem led to the next.

I am hoping that gives potential contributors enough context to avoid having to reverse-engineer months of experiments from the commit history.

## Alpha Status

The safety philosophy has not changed.

FabScan only commands controlled X/Y tracing motion. It does not control Z, the torch, spindle, THC, Cycle Start, or any cutting process.

The real-machine follower is still deliberately conservative and uses bounded coordinated moves with independent safety checks and HOLD behavior when it cannot identify a continuation it trusts.

I am calling this **alpha** because I think the basic architecture has now been validated well enough in simulation and on the real machine that outside review would be genuinely useful.

If anyone has experience with LinuxCNC, machine vision, robotics, controls, state estimation, path planning, OpenCV, or simply sees a better way to approach part of the problem, I would appreciate comments, criticism, testing, ideas, or pull requests.

The goal is still pretty simple:

**A practical open-source LinuxCNC camera tracing tool that can capture real shop-floor geometry and produce useful DXF without trying to become a CAD system or machine controller.**

It is not finished yet, but I think it is getting close enough to be interesting.

Then you should not need any python code use just rules

there is no 3 states only on off because you only have on and off hal output and this can only use a single hal reader

That's a StatusLabel connected to the status channel, not a hal bit pin.  And the logic is in the user_button.py file.

just an fyi why are you destroying the format and look of the ui.. your better than that!

I thought I was keeping the look quite true to your original.  Same background colors, container shapes, borders, padding, etc for everything but the DRO.  I wanted a bigger display for the main DRO and had the real estate.  I even used the exact same halbar color scheme for the axis load indicators as you did on the spindle load bar.

As for format, I've mentioned a number of times (in other threads) I don't want/like any controls in the user interface that can cause physical machine movement.  If I could get rid of the cycle start/stop buttons, jog panel, go-to-home/zero buttons I would... but those are in the base probe_basic.ui files I cant touch without going way off the reservation.

I understand having on-screen control buttons for the ATC and probing - those are just too convenient and would take up a massive number of physical inputs to replicate.

My physical control panel has all the 'standard' controls I need for routine machine operations: start/stop/feed-hold, jog, FRO/SRO/JRO/RRO, spindle control, flood/mist/blast/wash, plus man/mdi/auto mode and a home-all button plus a few undesignated spares.  I like tactile controls and think touchscreens are dangerous... same opinion about modern cars, in fact.

So my compromise is to accept what's in the base ui, but change everything I can to indicators vs. buttons/controls. And get rid of the 'danger' buttons (DRO auto-zero HAD to go).  Your somewhat-recent modification to permit keyboard jog disable was a huge win in my book!

I just pushed the changes to qtpyvcp for the halbutton flash option property in qtdesigner

You rock.  I'll have a go at it tomorrow evening and report back.

here is the flashing stylesheet code:

I just pushed the changes to qtpyvcp for the halbutton flash option property in qtdesigner. it will take it about 20 minutes to build and be available via apt, once you see it pop up in sudo apt update you will have the functionality you can adjust the stylesheet to give you whatever colors you want for the checked state flash primary and secondary colors!

just an fyi why are you destroying the format and look of the ui.. your better than that!

there is no 3 states only on off because you only have on and off hal output and this can only use a single hal reader

and i am adding a flashing property to button widgets because thats a good idea..

 

That's really slick!

Any thoughts on the three-state label I mentioned?

PAUSED state is blinking.

ok yeah this is what you want to do it is much cleaner with no code changes to hack it up, this is existing hal code and the button itself is none functional in the ui essentially becomes a label, you cannot click it or select it or do anything bu observe it physically.

you then just add your net in postgui.hal file and your off to the races!

here is the stylesheet used:

doesn't have to be, you can give it no focus, im tinklering with it now just about have it and it is pretty easy with no code changes and making more of them would be way faster and not require code changes for each instance