Advanced Search

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.

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?

Here are the Hal and ini files.
Thanks

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

I still have machines running LinuxCNC (named EMC2 back then) on Ubuntu 8.04, and 10.04 and...
It is all dependent on how you look at things, but i would definitely not discard parallel port as it is extremely reliable, extremely cheap be it as a old PC for 20-50$ or add on card for 10-15$, does not need a BOB (although it is recommended for new users as it adds a bit of safety for wiring).
Overall, when you realize you can have a fully functioning and very reliable machine control for under 50$,that will control whatever contraption you can think of by adding some cheap drives and motors found on old photocopiers, the possibilities rise sky high.
So no, parallel port and 32bit are not obsolete, nor will they be any time soon, they are the perfect setup form learning CNC on a very low budget.
Go out, scavenge some motors and belts and linear rods, build something, then build something else even better, then...
-
Personally i use Mesa cards for everything and by now i have installed over 70 or 80 or 100 (probably more but i have no clue of the exact number), but still sometimes i build machines using a parallel port, even plasma machines that produce huge amounts of interference and THCAD wired directly to parallel port with no BOB, using HF start plasma sources work perfectly but do require very strict wiring and shielding and grounding.
Visit the "show your stuff" section, find topics started by me, plenty of pictures and videos of machines i have built and/or retrofitted, and some other stuff...