Advanced Search

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

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.

Hi folks,

Is this still possible (on Debian 12) or would you advise upgrades ?

Thanks
Rob

 

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.