Advanced Search

Hi everyone,I'd like to add some safety conditions for enabling the spindle on my lathe.The spindle should only be allowed to start if all required conditions are met, for example:

• The auxiliary drives are enabled.
• The chuck is clamped (clamping pressure is present).
• (I may add more conditions later.)

My first idea was to simply combine these signals with one or morecomponents and use the result as the spindle enable signal.Something along the lines of:Is this the usual way to implement this in LinuxCNC, or is there a better or more recommended approach?How have you implemented spindle interlocks on your machines?Thanks!

rodw wrote:

2.9.10 has been released. Maybe try it.
 

We don't have a 2.9.10 .iso yet. I will try to generate one today. 
 

I've not seen any macros or subroutines ever posted for C-axis milling.

There have been a couple of polar interpolation posts, but nothing I'd call 'universal.'

You might look at this:

forum.linuxcnc.org/show-your-stuff/53476...rical-mapping#308478

Note that Fusion360 appears to have (somewhat recently) added a feature for polar interpolation mode.  Rather than using a machine's built-in polar interpolation F360 outputs XC moves directly instead of XY.

I've not tried it yet, but worth a look.

Have been considering buying a stepper motor and some parts and seeing if i can make them 'function' before i invest the time into the steel to build the machine

I think that's a good plan. Then maybe work on using that motor to operate a CNC backstop, for example, if you have a manual press-brake already.

Hi all! 
I came having problems when trying to run a new probe routine after running a program in QtDragon, a "cannot switch pages while in AUTO mode" message appears but only affects to te PROBE tab all the rest seems to work fine.

I try to solve ending programs with M30, pushing STOP button, switching to MDI before MANUAL mode but no way.

I´m running linux uspace 2.9.0~pre1, kernel 6.1.0-28-rt-amd64 in LMDE 6 Faye (Cinnamon 6.4.8) and using BasicProbe

Can it been fixed easyly or it would be better to upgrade to a new fresh realese?
 

So, the .pts files contain a path on the surface of a 3d model as consecutive 3d points and you are trying to post process this to create 4axis (xyzc) gcode where the c axis keeps the tool perpendicular to the model surface.

Seems you are basically trying to use a python filter script to do what a CAM and post prosessor would usually do.

You could use dx and dy from the pts file to calculate the tool orientation angle in the xy-plane (ie the c axis value) that keeps the tool perpendicular to the path segment. In order to keep the tool positioned on the work piece while the c-axis moves you need TCP kinematics.

The 1mm tool path offset could possibly be achieved by simply using a 2mm bull nose bit (depends on the required detail resolution of course).

If you need to use smaller tools then you would likely need to calculate new xyz coordinates to compensate for the 1mm offset and tool radius compensation.


Of course, the proper and easy way to do this would be to use a CAM

Thanks so much Peter,
I will make a note to grab 7i96sd_esdid.bin.

If anyone else comes across this in the future and wants to do index homing and have Delta servos I am now almost sure the Delta B3 drivers can home internally. (B2s can not).
You would wire the switch/sensor to the drive, not to the Mesa and then set up speed parameters and such in the drive. For homing, you'd then send a command to the drive to home (one DO) and once homing was done, the drive would report back to the Mesa (one DI) that the homing was done. 

However, I have B2 drives for XYZ and one B3 coming in for a rotary build hence why I needed to do index homing via the Mesa. 

2.9.10 has been released. Maybe try it.
If the installer fails its on the Debian side (or hardware). I was chatting to an experienced user in NZ just this morning with problems but he did manage to get it working. The ISO he had was working on other PC's.

I think it will work

Very cool Tommy. Now if you have a compatible video system or switcher, you can use an NDI App on your phone and you can go wireless on your network. I've been using NDI with a Rodecaster Video S for overhead shots wirelessly from my Pixel phone! Rode have a free app for Iphone.

This machine is still waiting for the files it has to use, so still with me, and of course i had to play a bit with it tonight as i do have some sample files to play with that may or may not end up what we use.
I might have chased the wrong rabbit when i built this, so a bit of TCP exercise is in order...if i get the chance.
Any advice that might save me time, please do chime in.
Thank you.

Thanks for the reply guys! It certainly would be awesome to build something open source that works. Ill admit, I am mechanically minded and certainly not smart when it comes to programming. I attempted to use AI to write something and whilst I got it to make some nice GUI screens they still werent how I would operate a press brake. Have been considering buying a stepper motor and some parts and seeing if i can make them 'function' before i invest the time into the steel to build the machine

Setting up a c axis with a turret milling spindle,  has anyone written any subroutines/cycles to make milling square/hex/oct/triangle shapes. 
such a cycle would have to take into account tool radius, distance from zero,width of shape (in respect to tool width). 
If not , looks like i have a bit of maths in front of me...
- I wrote a set of cycles 12+ years ago and uploaded them here that were for quick program creation (they calced tool change position etc for multiple tools) after changing jobs over the years etc, I looked it up and it seems that once uploaded the forum had corrupted them, I downloaded the mess and got them to work for the current machine i use. I probably should tidy them up and upload them again!.

LinuxCNC 2.9.10 has been released.

"What happened to 2.9.9?" you might ask. The answer is that it was briefly
released then withdrawn when it was found that a bug-fix had broken
existing configs which were working-round the bug. 
Context in this [forum thread](forum.linuxcnc.org/38-general-linuxcnc-q...rd-behaviour?start=0)
 
Changelog for 2.9.10:

  * Merge pull request #4219 from grandixximo/fix/4216-applied-tlo-params
  * tests: restore #5401-#5409 loaded-offset assertions
  * interp: split loaded vs applied tool offset params (#5401-#5409, #5081-#5089)
  * Merge pull request #4211 from BsAtHome/fix_libboost_python-versioning-2.9
  * build: Select the libboost_python matching the python version.


And here is the 2.9.9 release note: 

This is a bugfix, feature improvement, and security enhancement release. 

To address the last part first, it has been noted by two separate people
that a weakness in the RTAPI allows for privilege escalation as it runs
as setuid root (to give direct access to hardware). 
Given the use-case for most LinuxCNC machines this is unlilely to be a
problem in the majority cases; most hobby users will have root access
anyway. The issue has been patched in both 2.9 and in the development
branch.

Abbreviated Changelog for 2.9.9:

  * Merge pull request #4190 from tzuohann/check_config-2.9-datatypes
  * Merge pull request #4188 from grandixximo/fix/genclean-soname-2.9
  * Merge pull request #4122 from Sigma1912/2_9_gremlin_initialize_with_current_modal_gcodes
  * Merge pull request #4168 from grandixximo/backport/machine-coord-params-2.9
  * Merge pull request #4176 from hdiethelm/ci_doc_build_2.9
  * check_config: assert INI datatypes before comparing limits
  * Various CI improvements (little user impact)
  * Merge pull request #4166 from grandixximo/fix-4165-emccalib-iniref
  * interp: expose absolute machine position as #5021-#5029
  * emccalib: ignore ini refs embedded in pin names
  * Touchy: Backport updates from master
  * Merge pull request #4164 from grandixximo/backport/3996-tool-offset-params-2.9
  * tests: update tool offset assertions for #5401-#5409 applied semantics
  * docs: G38 probe to machine-coordinate conversion via #5401-#5409
  * interp: make #5401-#5409 the applied tool length offset
  * halscope improvements
  * gremlin: Initialize preview interpreter with active modal gcodes
  * Merge pull request #4022 from wucke13/dev/wucke13/backport-preempt-rt-detection-for-6.12-and-later
  * Merge pull request #4015 from grandixximo/fix/3994-axis-touchoff-jog-2.9
  * axis gui improvements
  * Improvements in Xenomai realtime support
  * Fix rtapi_app: Sanitize name for module addresses
  * radiobutton: A new HAL component to select between mutually-exclusive states
  * halshow: fix broken menu item: Watch -> Add pin/signal/parameter
  * Fix Gmoccapy screen resizing issue #3899
  * rtapi: Refuse to load uspace components missing rtapi_app_exit
  * Merge pull request #3898 from NTULINUX/2.9_libedit
  * Move python3-poppler-qt5 to "Suggests" addresses Debian bug #1129683
  * Move python3-poppler-qt5 to "Recommends". Issue #3872 addresses Debian bug #1129683
  * Merge pull request #3790 from mark-v-d/2.9 (lathe cycles)
  * hm2_modbus fixes
  * fix: emc/canterp: passing right value for SPINDLE_ORIENTATION
  * Adding testcase for 6bf62870da5866a237bdd8531e28f33644255164 endless loop in g71 fix.
  * If statement should not be nested. This causes the hal component to ignore the enable state of each axis range.
  * qtdragon - various updates
  * gmoccapy - various updates

The full changelog can be found at github.com/LinuxCNC/linuxcnc/blob/2.9/debian/changelog

As usual I would like to thank all the LinuxCNC developers and testers, especially the following who contributed directly to this release:

* Alec Ari
* Bertho Stultiens
* BsAtHome
* CMorley
* david mueller
* Hannes Diethelm
* Hans Unzner
* Jerry Trantow
* Luca Toniolo
* Mark
* mark-v-d
* Roy
* Sean Froome
* Steffen Moeller
* tzuohann

The LinuxCNC repositories have been updated for Buster, Bullseye, Bookworm, Trixie and Sid.

Note that released debs are also now available on the LinuxCNC GitHub under “Releases”: www.github.com/https://github.com/LinuxCNC/linuxcnc

Happy Machining!
 

I should note that existing firmware 7i96sd_esdid.bin has that setup:

Encoder A = Stepgen 0 Index
Encoder B = Stepgen 1 Index
Encoder I =  Stepgen 2 Index