Advanced Search

I don't know why 2.9.3 was removed either,[1] but 2.9.7 should be better. (basically just the same, but with bugfixes)
And if you have previously down;oaded the 2.9.3 image, don't you still have it somewhere?

[1] And it's almost certainly me who did it

If you need an RTAI version of 2.9.7 I will try to build one.

But given your reported issues elsewhere it might be worth setting-up to build from source. It's not especially difficult, though there is a oe-time investment in installing all the build dependencies.

Get the basic tools:
Then get the LinuxCNC source code:
Then enter the source directory and switch to the 2.9 branch
Now you are going to need a whole bunch of packages, dpkg knows what you need: (you need to be in the linuxcnc-dev folder , where you can see the debian folder)
The only complication here is that the build will be a run-in-place (can exist alongside a standard install) and to chose it you need to run a script.(Yes, it really is dot-space at the beginning)

I now have reliable switching between spindle mode (PV) and C-axis mode (CSP).
The key issue was not the controlword itself, but the fact that the commanded and actual position of the drive did not match at the moment of switching.To fix this, I’m using a small custom HAL component (c_pos_sync).
While in spindle/PV mode it continuously feeds the C-axis command position with the actual position (a “follow” mode).
When switching to C-axis mode, this offset is preserved — so there is no position jump and no mode-fluttering anymore.With this in place:

• M3/M4 work normally in PV mode
• M5 stops correctly
• M64/M65 switch to C-axis mode without instability
• G0/G1 C… moves work as expected
• Switching back to spindle mode is also stable

The zero-speed bit from the statusword is now used only for diagnostics, not as a gating condition for switching — this was the original cause of the Mode 3 ↔ Mode 8 oscillation.M19 is not fully tuned yet (separate topic), but it no longer affects the mode switching.I’ll attach the HAL file and the small sync component in the thread.

FwIw I have succesfully used a Macbook Air (with Linux installed) and a thunderbolt-to-ethernet adaptor to control a Mesa 7i96.

It is Linux so do not worry to much about security, and if you are worried yank out the internet cable.
Normally, if you do not click on some malware links in the browser or open e-mails containing malware, there is nothing to worry about, there are plenty of servers on public IP's that were never upgraded still working running Linux happily.
In short, if the machine works properly = never upgrade.
Long version:
I am fully aware of the psychosis caused by Microshaft spending billions on marketing to prove Linux is not secure, and they miserably failed as all Microsoft servers run Linux.
Windows will be someone else's property in 2 minutes flat if left on public IP.
The extremely bad thing is, that sentiment keeps getting perpetuated by lazy youtubers that play experts on youtube yapping about security being the same on both, it is NOT the same in any way, shape or form, and the worst thing is they talk about browser security that is close enough security vise but still not the same, while utterly ignoring the operating system security that is non existent on windows and extremely good on Linux.

You probably don't need ladder logic. I would think that it is do-able with HAL components. Maybe latch-on the spindle-enable when spindle commanded-speed is zero until measured spindle-speed is very, very near zero.

Maybe linuxcnc.org/docs/stable/html/man/man9/flipflop.9.html

I would need to experiment, but I am thinking setting "in" permanently to "true", clck being triggered by spindle-on ans reset triggered by spindle-off AND speed ~= 0.
(Spindle-off would be inverted spindle-on, and stopped status would use wcomp. )

This error appeared and continues to appear in versions 2.8.4 and 2.9.4 when executing G38.5. By tricking hal for version 2.8.4, the problem is partially solved.

It is impossible to verify that the problem has been solved in version 2.9.7 because a new error, “Queue is not empty after probing,” appears much more frequently in it (and in 2.9.4 as well) -
forum.linuxcnc.org/38-general-linuxcnc-q...bing?start=10#338958
github.com/LinuxCNC/linuxcnc/issues/3650

I already ordered a tube of Klüber LDS18, according to one of Rotary’s videos, this is the right stuff for the spindle.

It’s really unbelievably helpful to have resources from someone restoring the exact same lathe.

Make sure it's good grease!

Once it's in, it ain't comin' out.

You don't _need_ ladder for spindle orient, but you will need, at the least, some HAL logic and a second PID controller for position mode.

Mb2hal version didn't work great. I'm working on python hal component currently.
Meanwhile I made python app to drive FC01 inverter.
Available : github.com/dangervoid12/VFD-FC01-Monitor/tree/main

Do you still get this error without the flipflops and filters etc? Noe of this HAL complexity should be needed.

If there is a problem (possibly with repeated G38.2 commands) than please raise an issue on the Github so that it can be tracked. Not everyone reads every forum post (I don't) and so the forum is not a good place to report issues.

github.com/LinuxCNC/linuxcnc/issues

That's a relief, I didn't want to think that I had introduced yet another error when fixing something else.

If you are writing an interpreter to plug into LinuxCNC than it should probably be written in the same language as the existing one. That isn't to say that Python couldn't be made to work (I don't actually know) but there would be more to copy and adapt in C++

RotarySMP wrote:

... Starting over I would probably have just injected a little fresh grease. It is easy enough. 

 

OK, so I can just do that and tell myself I’m not being lazy — it’s science. We’ll make an A/B test and see how the machines behave over the years.
Yes, that sounds like it could actually be a thing.