Advanced Search

I appreciate the replies. I ended up ripping both boards out and replacing with new. Now I'm dealing with a whole other can of worms, but I appreciate the responses regardless.

I definitely see some oddities surrounding pausing here on my test config in a Virtual Machine without even having to simulate your exact configuration.

Let me do some digging and find out when it broke, and then go from there to see what needs to change to fix it.

This may be really quick or take me a few days, it's honestly hard to say ...

Bei mir lieber nicht davon ausgehen, dass ich etwas weiß . Umso mehr freue ich mich gerade, dass LinuxCNC startet und ich in der hal show meinen testweise angeschlossenen induktiven Näherungssensor sehe und dessen Zustandsänderung. Prima! Inzwischen sind meine ethercat Treiber für die Schrittmotoren angekommen, man sind die klein. Der freundliche Chinese hat mir eine dazu passende xml Datei geschickt. Wie bekomme ich die verheiratet?
   

I am doing some planning for the next major step in FabScan, my open-source LinuxCNC camera tracing project, and I would appreciate some input from people who understand the LinuxCNC motion layer better than I do.

FabScan recently reached `v0.6.0-alpha.1`.

Project:
github.com/FabLabRacing/FabScan

The current version follows a physical profile using a camera, persistent world-space path state, connected-path look-ahead, a planner, and a separate controller/safety layer.

At the moment, real-machine following is deliberately conservative:

capture frame
→ update path belief
→ plan bounded XY move
→ coordinated G1 XY move
→ stop / settle
→ repeat

That is now working quite well. On the latest difficult test shape, the real machine completed 800/800 planner steps without a HOLD, with most of the trace within a few thousandths of the exact SVG reference.

I still have some sharp-vertex work to finish before increasing speed, but I have started thinking about the eventual move from step-and-settle following to continuous velocity-based following.

My current development plan is roughly:

1. **Characterize the ceiling of the stepped approach.**

   Measure step size, cycle time, effective IPM, perception/planner time, accuracy, and HOLD behavior until I know how fast the current discrete method can realistically go.

2. **Measure predictor/dead-reckoning performance.**

   In the SVG simulator, feed the estimator camera observations at the actual achievable camera rate while predicting position/heading at a faster rate between frames.

   Since the simulator has exact geometry, I should be able to measure how prediction error grows versus time since the last observation and versus machine speed.

   The idea is to establish a real prediction/latency budget rather than guessing.

3. **Build the continuous loop entirely in simulation first.**

   FabScan already has a machine-dynamics simulator using the actual acceleration, velocity, and servo-period limits from my LinuxCNC machine.

   My thought is to let the planner produce a desired velocity/vector, let the estimator/predictor fill the gaps between camera frames, and let the simulated LinuxCNC/machine layer integrate that continuously.

   I would also test delayed/dropped frames, shrinking look-ahead, corners, confidence loss, and controlled deceleration to HOLD before trying it on hardware.

4. **Determine the correct LinuxCNC-native interface for continuous external motion.**

This last point is where I would especially appreciate advice.

Looking through the LinuxCNC Python interface, `JOG_CONTINUOUS` with Cartesian-axis jogging and teleop enabled looks like one possible route.

Conceptually, FabScan would want to update something equivalent to:

desired X velocity
desired Y velocity


at around tens of Hz, while LinuxCNC remains responsible for the actual real-time acceleration-limited motion at the servo rate.

I specifically do not want FabScan/Python attempting to become a real-time motion controller. LinuxCNC should continue owning that layer.

So my questions are:

Is Cartesian `JOG_CONTINUOUS` / teleop motion the appropriate LinuxCNC interface for this kind of sensor-driven velocity control?

Can the velocity of X and Y continuous jogs be updated repeatedly while they are already moving, without effectively stopping/restarting the jog?

If X and Y velocities are updated separately, does LinuxCNC treat them cleanly enough as a changing Cartesian velocity vector for this application?

Is there another interface inside LinuxCNC that would be more appropriate for continuously supplying an externally generated XY trajectory/velocity command?

And are there any particular concerns with doing this alongside QtPlasmaC, assuming FabScan continues to operate only while the machine is idle/manual and never controls Z, torch firing, THC, Cycle Start, or the cutting process?

I am not committed to any particular implementation yet. In fact, I would much rather learn that I am heading toward the wrong LinuxCNC interface before I design the continuous controller around it.

The project now has record/replay and an SVG ground-truth simulator, so once I understand the LinuxCNC side I should be able to model and test most of this before allowing continuous motion on the physical machine.

For anyone interested in how FabScan reached its current architecture, I added a `HISTORY.md` to the repository. It explains the earlier local follower and Corner Assist experiments, why the state estimator and connected-path planner were added, why replay led to the simulator, and what the first real-machine tests exposed.

Any advice on the LinuxCNC side of this would be very, very, welcome, especially from anyone familiar with teleop/jog internals, external motion control, or sensor-guided applications.

Thanks!!

sorry missed your reply.

its just bloody brexit
I bit the bullet tonight and ordered
430 euro will come in at about £440
I ordered 2 cards I have 3 machines in total, mill, router, lathe
gonna try to be cheap on the other 2 and share the same card and just make an interface plug. but for now only focusing on mill and maybe lathe.


m/c £250
card £220
...
future costs
dedicated touch screen laptop £180
New steel frame £100
MDI £200

I think I'll still land under my 1k budget

Were you changing your speed from 5000 to 1000 using the feed override or by changing the feed F command in your G-code?

Snowgoer, I helped Cutnweld with the upgrade. We are using Buildbot 2 on Debian Bookworm (MX Linux in this case). I upgraded the linuxcnc-uspace package using Synaptic Package Manager. The system has a lot of other OS and package updates that could be run but I opted not to do this -- last time we did, we had a huge nightmare getting networking up again due to Realtek NIC drivers compiled with DKMS. So I'm afraid to try kernel upgrades on a system that's working. 

Cutnweld's table has been running very happily for several years now but we wanted to address a bug related to material selection so hence the update to latest. That's when his problems started.

As he stated above, we downloaded deb 2.10.0-pre0.6259.g34c07071bf_amd64.deb and installed manually. The QtPlasmaC version displayed is the same as before, though. Let me know if you have any other technical questions and I'll try to answer them.

Keith3D wrote:

Hello Forum,
I have been wrestling with getting linuxcnc to run on a flask app on localhost for now.

What does that mean?
For setting the network:
forum.linuxcnc.org/27-driver-boards/3559...ethernet-mesa-boards

Actually installed .deb file 2.10.0-pre0.6259.g34c07071bf_amd64.deb, it did not change QT tho, it is still on newest version. Update on action, it does not seem to have much of a schedule, back to reversing along cut path when I hit pause, it would be cute if it was younger but it used to be so well behaved The reason for update was a cut material bug we didnt like on the older version, Is there a way for me to find out which version I had been running?

I broadened the scope of the flash to all widgets in qtdesigner and went ahead and updated the cycle start button to flash on pause, much nicer and more noticeable without being a blight on the ui in bright yellow.. I hate yellow...lol

I am not able to understand what was done in the video (the one using AI in Fusion 360). maybe it is me.
 

I got to thinking, it might be helpful to see a comparison image, the image on the left is the actual image used for testing, the center is a trace using the simulator, and the right is an actual trace done on my machine. 

Hello Forum,
I have been wrestling with getting linuxcnc to run on a flask app on localhost for now. I can never seem to get the machine out of estop, power on, home and jog. I also tried using halcmd to do this. Same thing was happening. Is it even possible to do this? 
I have 2 boards, Mesa 7i95T and 7i96S. I have Linuxcnc 2.10~pre on an I5 computer and have also run  2.9 ISO on a stick to do this.
Thank you for your support,
Keith

My layout (no cabinet yet) is very messy, but here's an old photo of it:
www.delorie.com/photos/cnc2/PXL_20240324_210728573.html
I went with DIN rails for mine, one for mains power control (top) and one for low voltage (middle).  The mains rail has circuit breakers and contactors, and the contactors are wired into the estop chain.  The main logic power's contactor is wired into the on/off buttons so it defaults to off after a power failure.
You can mount power supplies on their sides if you need to save space.
Don't forget to leave space inside the box for vents and fans top and bottom.
Your estop should be more conveniently located.  Or buy more than one of them

Thank you Andy.
I did get the .tcl version running, but it is tied to Axis so the Reload button doesn't appear for PathPilot.
I will give the python one a try, at least there is then a hope of tying it PathPilot somehow.