Advanced Search

You could set up a prox or mechanical switch in the saddle to detect the tailstock and abort homing. This might be easier to wire than a dedicated tailstock detector, given that you are probably already running a bunch of wires to the saddle.

My own lathe has resolvers, and I modified the Mesa resolver driver to work in conjunction with the LinuxCNC .var file to give me absolute homing (most of the time) That means that most of the time my lathe homes without moving at all.

wiki.linuxcnc.org/cgi-bin/wiki.pl?Psuedo-Absolute_Encoders

spumco wrote:

Why do I get the feeling this is not the first time you've looked at failed (or suspect) industrial components?  Spend any time involved with, or doing, NDT/NDE?

I spent 12 years at Sheffield University doing postdoctoral research on cracks of various sorts. 

andypugh wrote:

The moment is greater further from the shaft end, and a ball bearing isn't particulary stiff against torsion. Also the step that the bearing butts against, if machined poorly, might be a stress raiser. 

Why do I get the feeling this is not the first time you've looked at failed (or suspect) industrial components?  Spend any time involved with, or doing, NDT/NDE?

I have never found a use for encoder_ratio, at least partly because it relies on software-counting of the A and B phases.

If you are using a Mesa card then encoder_ratio won't help you.

But gear hobbing is nevetheless very possible. I do it regularly. I invented the idea of electronically geared hobbing, but I probably didn't invent it first

wiki.linuxcnc.org/cgi-bin/wiki.pl?Hobbing

Note that due to a problem with a certificate on the server that hosts the Wiki, https won't work. This means that to download the linked zip file you will need to copy the URL, edit out the "s" in "https" and then paste the URL back into the address bar. Sorry about this.

kevin_allein wrote:

How do other people deal with that ?

Most CNC lathes I've seen with a moveable tailstock I've seen fall in to the category of 'Operator Beware'.  Z-home is set to max positive travel, minus the tailstock length and bit for clearance.  If you've got the tailstock anywhere else and locked down you're in trouble.

I've seen one lathe - can't remember the brand - with a tailstock-in-place switch.  If the tailstock was parked in the usual location (right end of bed) the machine homed normally.  If the tailstock was not present at the switch homing wasn't permitted - an operator message "reset tailstock" was flashed on the screen.

I don't know what the procedure was if the tailstock were removed completely for long jobs... maybe an OEM-approved switch bypass device that indicates to the control the new do-not-exceed Z-pos value?

Cooking up a switch-based homing interlock shouldn't be too hard, but I'm not sure exactly how to go about it without writing a custom homing sequence.

spumco wrote:

Wouldn't misalignment between motor and driven component tend to break outboard of the bearing?  That's assuming the bearing didn't come with lots of negative preload from the factory, of course.

This is one of those cases where, given the final result, I can think of a plausible explanation. But that would be true in either case...
The moment is greater further from the shaft end, and a ball bearing isn't particulary stiff against torsion. Also the step that the bearing butts against, if machined poorly, might be a stress raiser. 

andypugh wrote:

I think we would need a better macro photo to tel if that was a fatigue failure or not, but it leads me to be rather suspicious of the motor-to-shaft alignment and mounting. Is there any type of flex-coupling there?

I couldn't make out any beach marks on the surface. A macro would be interesting, as would pulling the bearing shield/seal and checking for signs of heat or abnormal conditions.

Wouldn't misalignment between motor and driven component tend to break outboard of the bearing?  That's assuming the bearing didn't come with lots of negative preload from the factory, of course.

If you are looking for on site assistance, it might help to start with saying where you are located. There are Linuxcnc users all over the world. (And a few might even have spare time to pop in and give you a hand.)

Cherna post=325580 userid=43095My worry was that I was missing something that led other (more knowledgeable people) to mark this chipset as not working with LinuxCNC, but as you said if it works, it works.

Hopefully this post helps someone in my same situation in the future.

Thanks a lot for your answer.

If a card has a history of not working in the past, but does work now, the most plausible reason is that kernel updates added support for the chip used on that board.  The Linux kernel is continually being updated adding support for new hardware, and there is often a bit of a lag from a chips introduction, to inclusion in the kernel, plus add the fact that the real time kernels used by Linuxcnc are never bleeding edge.

Could've been an expensive trip if you went through the gyprock, was it one of those times you could see what was going happen next, lol.

I got the machine to open now.
But when i try to home the axis it gives me a "Joint.0 following error"

Attaching my current X set-up here.
I'd be greatful if anybody finds some time to look over it!

CODE:
#**********************************************
# X Axis (Joint: 0 / Output: 0)
#**********************************************

# PID Setup
setp pid.x.Pgain [JOINT_0](P)
setp pid.x.Igain [JOINT_0](I)
setp pid.x.Dgain [JOINT_0](D)
setp pid.x.bias [JOINT_0](BIAS)
setp pid.x.FF0 [JOINT_0](FF0)
setp pid.x.FF1 [JOINT_0](FF1)
setp pid.x.FF2 [JOINT_0](FF2)
setp pid.x.deadband [JOINT_0](DEADBAND)
setp pid.x.maxoutput [JOINT_0](MAX_OUTPUT)
setp pid.x.error-previous-target True
# limit stepgen velocity corrections caused by position feedback jitter
setp pid.x.maxerror [JOINT_0](MAX_ERROR)

# joint-0 enable chain
net joint-0-index-enable <=> pid.x.index-enable
net joint-0-index-enable <=> joint.0.index-enable

net joint-0-enable <= joint.0.amp-enable-out
net joint-0-enable => pid.x.enable

net joint-0-enable => hm2_[MESA](BOARD).0.stepgen.00.enable

# Joint 0 Step Generator Settings
setp hm2_[MESA](BOARD).0.stepgen.00.dirsetup [JOINT_0](DIRSETUP)
setp hm2_[MESA](BOARD).0.stepgen.00.dirhold [JOINT_0](DIRHOLD)
setp hm2_[MESA](BOARD).0.stepgen.00.steplen [JOINT_0](STEPLEN)
setp hm2_[MESA](BOARD).0.stepgen.00.stepspace [JOINT_0](STEPSPACE)
setp hm2_[MESA](BOARD).0.stepgen.00.position-scale [JOINT_0](SCALE)
setp hm2_[MESA](BOARD).0.stepgen.00.maxvel [JOINT_0](STEPGEN_MAX_VEL)
setp hm2_[MESA](BOARD).0.stepgen.00.maxaccel [JOINT_0](STEPGEN_MAX_ACC)
setp hm2_[MESA](BOARD).0.stepgen.00.step_type 0
setp hm2_[MESA](BOARD).0.stepgen.00.control-type 1


# joint 0 pos/vel/fb
net joint.0-pos-cmd <= joint.0.motor-pos-cmd
net joint.0-pos-cmd => pid.x.command

net joint.0-pos-fb <= hm2_[MESA](BOARD).0.encoder.00.position
net joint.0-pos-fb => joint.0.motor-pos-fb
net joint.0-pos-fb => pid.x.feedback

net joint.0-vel-cmd <= joint.0.vel-cmd

net joint.0.output <= pid.x.output
net joint.0.output <= hm2_[MESA](BOARD).0.stepgen.00.velocity-cmd

net Joint.0-vel-fb <= hm2_[MESA](BOARD).0.encoder.00.velocity
net joint.0-pos-rawcounts <= hm2_[MESA](BOARD).0.encoder.00.rawcounts
net joint.0-index-enable <=> hm2_[MESA](BOARD).0.encoder.00.index-enable

# Encoder
setp hm2_7i95.0.encoder.00.counter-mode 0
setp hm2_7i95.0.encoder.00.filter 1
setp hm2_7i95.0.encoder.00.index-invert 0
setp hm2_7i95.0.encoder.00.index-mask 0
setp hm2_7i95.0.encoder.00.index-mask-invert 0
setp hm2_7i95.0.encoder.00.scale [JOINT_0](ENCODER_SCALE)


# Home
net home-x => joint.0.home-sw-in
net x-neg-limit => joint.0.neg-lim-sw-in
net x-pos-limit => joint.0.pos-lim-sw-in

unknown wrote:

And to add insult to injury I bashed my little toe and just about broke it, I couldn't find my steel capped thongs.

I think my toe did break and is almost healed now, Slipped in bathroom, skewered thru the door, left toe behind, and nearly busted the wall sheeting on the other side of the halway.......

I've discovered that if I click inside the grid (where the ZX axis is shown), the movement buttons work, but at maximum speed, when I press the + key, it starts working as it's supposed to. When I click somewhere else, it stops working, and I have to do everything again. I assume it's due to some unknown issue.

I've also noticed that the maximum motor speeds increase at random startups without making any changes to the files.

The movement keys on the keyboard are still like a mill and aren't very comfortable to use.

I think I might just look for a toaster oven and mod that (or use it as is), the local op shop (thrift store,goodwill) has some pretty good prices.....picked up a monitor arm, complete and still in the box, for AUD $6.50.

LFQP & TSSOP all with .5mm pitch are no issue, just those damn 0603 parts with non hand solder pads, in my defense (a very poor one) I didn't design this board & we're dog sitting another Beagle.

The bit that gets me is that I soldered the FPGA, ethernet interface chip and bus drivers on first, see what you get for following instructions.

I think it was just a case on general (temporary?) stupidity on my part.

And to add insult to injury I bashed my little toe and just about broke it, I couldn't find my steel capped thongs.

 I deal with pcb's on a daily basis and the aforementioned hand place pad size thing happens a lot.. Along
with reversed silk screen polarity for diodes, leds, and caps. And that's before performance testing.

Unknown If your looking for a pick and place you may want to check out the LumenPnP,
www.opulo.io/
though I  don't have direct experience with them, they may be worth checking out.

  If you are looking to do a retrofit be ready to write a lot of extra code to control the machine. For
example feeders and auto alignment camera's.