Advanced Search

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

You can always  use pncconf/MesaCT to create a sample configuration
to copy/paste from, if you don't want to possibly corrupt your hand edited file.

The defaults for the torque homing must be good enough. i can see the carriage hitting the bearing block and the motor tries to push past it for like 2 seconds but it's not pushing strongly. You can see the encoder feedback not move anymore, and then it rolls backwards looking for the z pulse. If you're scared just unhook the coupling and stop the servo shaft with some pliers. If you're going to use absolute encoders you'll need to home the machine using the normal config, and then disable all the cia402 homing stuff and enable the absolute encoders. You still have to press the home button but it won't do anything. The way i dealt with this change is I have a branch in my source control where homing is enabled, and the main branch with absolute encoder config. if i disassemble the machine or unhook the encoder cables, i just boot linuxcnc on the other branch, home, and then switch back to main.

fer662 wrote:

What is your status? Maybe I can help out but i already posted most of my experience getting this to work on the absolute encoder cable thread, i think you were in there. 

Was curious if you needed to adjust the hard-stop scheme as I might try it tonight or tomorrow - didn't want the servo to take off and ram an axis into oblivion if I'd misunderstood the A6 manual.

Here's a current status over-share:

• Can jog XYZA axes.  Have not checked accuracy, but it's not orders-of-magnitude off.
• Have not tried any homing yet, either cia402 or native LCNC
  • Drives programmed to use A6 'move-to-switch, back to index' (#3 & #4)
• Have cia402homecomp.comp installed, plan to use that but a little hazy on the entire sequence, especially managing the inevitable offset between switch location and index signal.
• Idea of zero home/limit switches is attractive.
  • I'm tempted to just bypass all homing BS and manually move the axes where I want, then set the encoders to zero and set LCNC to home-in-place.
• Current delay is getting the carousel-type toolchanger working.
  • Tried to use existing carousel.comp, but that was a big fail as I wasn't interested in massive overhaul of my existing M6 remap sequence.  Major problem was that carousel.comp tries to hunt for an index signal at every startup (in index/counts modes).
  • Have an AI-assisted carousel_eth.comp config 95% complete, maybe testing tonight.
    • Uses the cia402 absolute encoder feedback, so no index or per-pocket sensors needed.

Before any other evaluation, check the spindle bearings to see if they are capable of handling real radial loads.

Manual or semi-auto drill/tap machines may not have angular contact (or tapered roller) bearings as they are only intended for axial loads.  It would be rather a shame to discover you can't do any reasonable side-milling without a major redesign of the spindle.

I've no idea what the situation is in your country, but if used machine tools are that expensive I'd think a self-built thing from scratch would be better than that Burgmaster.

I haven't had to tweak any specific parameters for this. I basically had cia402 homing working with the sensors for X and Y and when i designed my Z carriage i messed up the location of the endstop sensor (i'd trigger going downwards, too many sleepless nights haha), so i went and changed the homing method to -1 and it worked on the first try. I went and tried it for the other axis, also worked on the first try. What is your status? Maybe I can help out but i already posted most of my experience getting this to work on the absolute encoder cable thread, i think you were in there. The issues i had pending to resolve were completely unrelated to homing, just some parameters i had changed from the defaults via sdoconfig, and those stay even if you remove them from the XML. When I figured out what they were it fixed my coordinate system woes.

Hello,
I'm investigating a lathe retrofit on a Colchester 4000L Fanuc 0T-A.

I've done a couple of retrofit/hybrid, and 'from scratch' LinuxCNC machines before, but none involving Fanuc, which I know is often difficult-to-impossible depending on the particulars. I've looked at numerous paths forward balancing time/difficulty vs up-front cost. 

Been reading old manuals, searching the forums, and I must admit, taking a significant amount of input from ai, and I have a plan. But, while it was nice to seemingly make rapid progress compared to my previous projects, I would be glad of input from other actual humans. If CNC has taught me anything, it's don't trust a machine! I've tried to include enough relevant detail without turning the post into War and Peace.

===
I'll be using MESA boards - most likely a 7i96 connected to a 7i77. I already have them from a previous project where they worked very well.

For axes, I want to keep the Fanuc motors (red caps: A06B-0513-B032#7000 amd A06B-0512), and (for now) their drive/VCU (it's a dual axis unit A16B-1200-0520). 
If I've understood correctly, LinuxCNC can read the positional feedback from the encoders via serial port on the 7i77, then using DC injection to find the magnetic offset, generate commutation data and command the motor via 7i77's 10V into the pre-existing VCU. 

I'll Keep the fanuc spindle motor, an 11kW A06B-0745-B201, which seemingly has an encoder with ABZ output that LinuxCNC can use via encoder input on the 7i77. 

I'm replacing the spindle-driver/VCU (A06B-6060-H008) with a heavy duty VFD. Something like a Yaskawa GA70C2056BBA. The failing fanuc spindle driver is actually the straw that broke the camel's back and instigated this project.

Toolcahanger is a duplomatic BSV-160. There seems to be ample history for successfully using similar units.
Coolant pump is either on or off, I think it'll be OK.

Control will initially be primarily PC based, probably some touch-screen, but will probably add a pendant for easier manual positioning and the dopamine hit of pushing real buttons.

Really just wondering if anything is obviously foolish. 
 

fer662 wrote:

-1 and -2 definitely work. i'm using them

Thanks for the confirmation.  I just went through what now appears to be a pointless re-wiring exercise connecting limit switch signals to my axis drive digital inputs. (new servo installation on existing machine)

Have you modified/tuned the C10.30 - C10.32 parameters for hard-stop homing?

If so, can you share the mechanical arrangement and parameter values?

The powersupply was the problem. I am glad that it died instead of my mesa.
I should have tested that yesterday instead of assuming that 5v no load meant the power supply was good.
Thank you for the quick response as always!

Flashing PWR lights usually indicate a marginal 5V power supply
It could also indicate a short on the analog outputs.
(if there is a problem with the analog outputs, the 5V power drain
will increase suddenly once the FPGA is programmed and analog power enabled)
 

1. ini file is missing

2. Take the config that uses AXIS gui (which apparently works), open the ini file and in the [DISPLAY] section change 'DISPLAY = axis' to 'DISPLAY = gmoccapy'. The config should now start with gmoccapy and jogging should work using the on screen jogging buttons.


3. Looking at the header in your hal file it seems that you are using a rather old prerelease of version 2.9 '# Using LinuxCNC version: Master (2.9)'
Unless there is a particular reason for this I would recommend using a more recent release (eg 2.9.10):
github.com/LinuxCNC/linuxcnc/releases#release-v2.9.10

So, does this mean I can get three index pulses onto a 7I96s in a faster, more proper encoder way and not have to use the isolated IOs?

Yes, it's possible to have 7I96S firmware that wires the 3 encoder inputs as step/dir index signals.

I tried turning on the cnc today to find that it had no connection to the PC. After opening up the back I noticed the /done and PWR leds were flashing.
I have verified that the power supply is outputting 5v when disconnected from the mesa. I then disconnected everything from the mesa (ethernet, and all I/O) When power was reconnected to the mesa I measured less than 1v.
Is this a short caused by a power surge? Or did the firware get corrupted?
Since the pwr led can't stay solid I haven't attempted switching the jumpers to the fallback firmware.

Any tips on what to check next?
Do I need to ship this out for repair or replacement?