Advanced Search

Yes, that’s correct. The signal is 1 Vpp, and I’ll be using an interpolator.

I was initially considering using Insize linear scales — I even bought them — but I came across some new HEIDENHAIN scales at a good opportunity, so I decided to go with a more reputable and proven brand.

It just seems like a very high price for a single cable. In fact, the price of the new cable is about the same as the price of the Chinese linear scale .

 

Daz_Rich wrote:

gonna try to be cheap on the other 2 and share the same card and just make an interface plug.

Might not be necessary as you can have 2 machines controlled by the same card and without moving any wires/plugs, as long as you need only one spindle speed and feedback control, the rest is easily manageable with multiple configs only.
Oh yeah, and if those two machines need more than 5 axis, find an IDC26 to DB25 adapter cable.

I changing the feed F command in G-code.
I also noticed that different tracks are driven for the F1000 and F5000.
For F1000, down to -10.80618622925091 mm.
For F5000, down to -10.77390521216340 mm.
Attached are the two scope files..

Gruß
Rüdiger
 

gravedigger wrote:

How different is the G-code between Mach and LinuxCNC? What are the main differences?
 

Basically, you should consider the g-code for Mach4 and LinuxCNC to be incompatible and under no circumstances run programs from one machine on the other.
Although simple code from a simple postprocessor will be executed correctly on both machines, this should be considered the exception, not the rule.
In extreme cases, running a foreign code will result in damage to the machine or injury to the operator, because there are codes that are written identically but executed differently. Such code will not generate an error, only unexpected movement.

Johnsinski wrote:

So I asked AI if Linuxcnc could help with this.

Inspired by your text, I also asked AI a question. Honestly, I'm surprised because I got the absolutely correct answer:

Can Intel i9 with 64 GB RAM control a microwave oven?

Yes, a computer with an Intel i9 processor and 64 GB of RAM can technically control a microwave oven, but this is a complete overkill. 
How is this possible? 
Processing power: An i9 processor and 64 GB RAM have a million times more power than needed to run a microwave. 
Connection: The computer must send signals through ports (e.g. USB) to an additional electronic circuit. 
Control: This additional circuitry (such as an Arduino or network relay) must physically push the buttons buttons or turn on the microwave's power.
Why doesn't this make practical sense?
Microcontrollers: A regular microwave uses a small, simple chip (microcontroller) that costs a few dollars.
Power consumption: A computer with an i9 processor uses a lot of power when idle, while a microcontroller uses trace amounts of it.
Safety: A failure of the operating system on a powerful computer could accidentally turn on the microwave without supervision. 

Well, either you asked the wrong AI, or you asked the question wrong...

I also use E cam

i have a post i modified main things i had to fix are threading g33.

everything else in the post i have checked works well i use it on a production cnc lathe running linuxcnc.
Ecam is absolutely awesome. way better than fusion 360 lathe cam in my opinion and i used both for 2 years

my post currently still has one issue left. when using g97 constant spindle speed the post still outputs a D value for max speed. and linuxcnc throws a error on this so currently i just delete that code from the file. but it's on the list to fix at some stage.

rodw, oh I saw you on youtube! The new motion.interp.heading pin looks to give you the tangent angle of the current point on a path? That seems helpful.

oh well, tried to attach gifs of the two motion strategies, but didn't work.

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.