Advanced Search

QtPlasmaC updates - Master (v2.10):

• Fix bugs and enhance Run From Line

QtPlasmaC updates - Master (v2.10):

• do a little less filtering of z moves with keep-z-motion
• fix gcode filter copy/paste error
• fix modifying\creating new materials via magic comments
• add icons for Operator Text and Operator Display dialog boxes

MTTI wrote:

I’m not a programmer (only a bit of Python, and some BASIC and C). It took me the whole day to find this issue, moving a debug print line around the code to locate where it was getting stuck.Thank you for the explanations, and also for pointing out the second copy/paste bug, I’ve fixed that one on my side as well.

Now I need to follow up with Pronest, as the post-processor still doesn’t insert commas between the parameters...

Regards

Me either to be honest. I do this because it differs from my day job, gives me something new to continually learn, and because I enjoy it.

I appreciate your collaboration!

Andy, just found your orient.svg  which has encouraged me to have another go. Especially as I realise the function could be useful when probing.
Thanks for your clarification.

Is the grayscale encoder aligned to the carousel (ie, it corresponds 1:1 with the tool pockets) or is this an encoder on the motor?

The "gray" mode of the carousel comp is intended for the former case.

If it's a motor-mounted encoder look at using "counts" mode. (with an encoder counter that is scaled to the pocket spacing)

Dudelbert wrote:

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

Agreed.

When I was fixing my TorCAM CNC, there was literally nobody else who had the same machine, which was certainly suboptimal.

It's great to be able to learn from somebody else's mistakes.

Segfaults are typically problems with the linuxCNC software writing out-of-bounds.
Are you running any custom HAL modules?
Which HAL components are in-use?

Sorry, but RTAI support has been a bit lax lately, though I am still committed to it at least in 2.9.

What would be really useful (including to me) would be a flowchart that tracks a simple G-code command (like coolant-flood) from the Interpreter to the HAL pin.
There are so many layers and abstractions (not all of which seem necessary)
Oh, and a clear indication where the switch to realtime happens in this flow would be helpful too.

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