A couple of issues: Homing and Joint Following Error.

Hi guys,

I just got back from a month long startup in Atlanta and I'm back on the lathe project.


We got it to move, and the machine would move in the negative direction (opposite of the direction that it should go) by .5 inches. Curiously, when I created a new config file this amount was cut down to .05 inches for the home search for this config as well as for all of my other LinuxCNC setups. Where did that get stored?

I've tried the various ways of setting the home direction per the Homing How-to, but no luck.

We also get "Joint 0 Following Error" whenever we try to home,

And when the machine starts off, the position of the X axis drifts continuously. LinuxCNC doesn't make it hold its position.

Jogging doesn't work.

The setup is a 1980's Takamatsu lathe with Yaskawa drives and encoders. The encoder for the X axis sure appears to be setup in the correct direction.


Thanks for any help,

John

Actually the wiring is fine, what would make you suspect otherwise is a mystery to me.

The E-Stop has control of the drives and drops them out via the external hardwired E-Stop button, as well as from inside LinuxCNC.

This in turn drops out the contactors for the drives, reprieving them of power. The overtravel limits drop out the direction relays in the Yaskawa X and Z axis drives, and are hardwired to the drives and are functioning as expected.

The lathe has to be turned on via the Start PB before the drive contactors are energized. And the Stop button (as well as the E-Stop PB of course), will stop the lathe as intended, also dropping out the drives. This has all been checked out and works fine.

This is mostly done externally via ice cube relays.

The door switch, if it exists, has yet to be included in the system. If it doesn't exist, then one will be added. I can either drop out the entire system, or simply stop the spindle. I'm open to suggestions on this.

Which does bring up a side issue, hitting the E-Stop in LinuxCNC shuts down the lathe and won't allow me to turn it back on until I close LinuxCNC and reopen it. I suspect this is just me not knowing how to reset the software E-Stop, and it is pretty far down aways on the list of things for me to worry about.

Not sure on how to make this "Safer". Other than installing a safety relay like a Pilz, which would be ridiculous. So I think that we have our bases covered.

But thank you for the link, I'll check it out.

Meanwhile, does anyone else have an idea as to what is wrong? For those following along, I forgot to mention this, but you can see my changes by looking for the "#JEW" (my initials) above the modified line.

What tommylight is referring to is the individual drive enables. If these are setup correctly
a continuous creep is impossible without faulty hardware because LinuxCNC will sense the drift and cause a fault (a following error). LinuxCNC being able to disable the drives when it senses a following error is a safety issue that should be addressed.

That's easy enough with our setup. At most it's a pin and a relay or two. I can interrupt the end stop limits to do a soft disable of the drives. I'd rather not cycle power on the drives more than necessary, they are getting a bit long in the tooth.


I'll wire this up tomorrow. Might fix things up.


Thanks for your help Peter!

No problem, I didn't suss out the need for for syncing the machine power to the actual drive. I thought that I was covered by bringing up the power to the drive. Apparently not...

The axis drives don't come with an enable input so I see three choices for creating an "enable" input of my own. Further complicating things is the absolute lack of info on these drives (and the entire machine for that matter). This has been one large Easter egg hunt...

1) Turn the power on to the devils when I get the "joint.0.amp-enable-out" and "joint.1.amp-enable-out" signals high in LinuxCNC. Easy to do since the infrastructure is already in place. This will only work if LinuxCNC enables both drives at the same time, and leaves them enabled throughout the entire job (I don't want to be cycling power to the drives unnecessarily).

2) Add a relay to one each of the overtravel inputs (plus or minus, it shouldn't matter) on the drives which will drop out the motion on the drives. Has the advantage of being able to isolate which drive is enabled and should be a kinder, gentler, way of doing things than cycling power. I'd probably have to interrupt the fault signal from the drives to the Mesa board while still feeding the actual overtravel into the Mesa card. A bit messy on the wiring side, but not too bad. Relay timing could be an issue though...

3) Interrupt the +15 and -15 volt power to the drives. I've already confirmed that the drives will not run without this power supply. Pretty simple, and I can isolate which drive gets enabled. But I hope option #1 will suffice.

I'm going to start with option #1, it should be just a matter of linking HAL signals together in the .hal file. If the drives end up cycling during operation, I'll go to option #2, messy or not.

Option #3 will only be used as a last resort since I don't know what side effects might pop their ugly head up at me by diddling with the +-15 rails. Although I really don't think that it will harm the drives. And technically, I have just observed the lack of motion while doing this, I have no guarantee that it will always operate this way. In other words, it might still allow enough drift to fault out LinuxCNC putting me right back where I started.

So I guess the big question is: Do the drives get enabled at the same time, and do they stay enabled throughout the milling operation under normal conditions?


Thanks again for all of your help!

tommylight wrote:

All the drives should have an "enable" input, even the cheapest Chinese ones have them.

That's been my experience, although the AB line of drives blur the lines with how you have to program an input to achieve this. I'm no fan of this way of doing things.

Here's the drive in question:

www.forum.linuxcnc.org/30-cnc-machines/3...4-wiring-help#178491

I got the drawing from Mr. Sato, and I created a CAD version of it. I don't see anything that would be the enable other than controlling the power to the drive. But that's a bit too ham-fisted for me. If the drives stay enabled during the operation of the lathe (outside of detecting a fault), and LinuxCNC doesn't cycle the enable on and off during operation, then I don't see a major issue with it, other than not being the normal way of doing things. But I think not.

tommylight wrote:

Those are meant for actually enabling and disabling the drives without the need to cut their power, so as a general rule:
E-stop can be wired to cut the power to the drives off, most drives have a separate power line just for that.

These don't. One contactor for the spindle, which does have an enable input, and one contactor for the two axis, which don't. You can see in the drawing that Mr. Sato gave me that they are intended to be ganged together off of one power source. The +_15 VDC and the faults are shared, as well as the thermal overloads.

tommylight wrote:

Enable has to be wired to all the "enable" pins on the drives, so they can be on or off all at the same time and in case of any error LinuxCNC uses that pin to disable all the drives. The pin should be "machine is enabled".

I'll interrupt the power going into the overtravel relays (break the connection at 3-1) and put a N.O. contact in series with it with the relays (one for each drive) controlled by the drive enable pin for that drive. I suppose that I could combine the signals in HAL, but we would be one upgrade away from losing that connection and functionality. This way the overtravel inputs work as normal (I might have to put pullup resistors on these inputs however), and the .hal file has to include the enable outputs to allow the lathe to function.

I might have to run the alarm circuit through another N.O. relay contact to prevent the drive from reporting a fault that originated in LinuxCNC and mucking up the reset procedure.

tommylight wrote:

Drive fault pins should be wired to separate inputs on the mesa board, so if any of them fails LinuxCNC can point exactly the drive that faulted and can disable all the drives and all motion to prevent from damage to the machine.

I'll do that as well, I haven't added alarms to LinuxCNC as of yet, and IIRC, it will have to be a custom setup in HAL since I don't remember seeing anything in PNC for this.

tommylight wrote:

The first two features have to be implemented and tested before any tuning or further setup of the machine.

Yup, no argument there. I had thought that LinuxCNC would simply take control of the axis. Which is not unheard of, but is unusual. And I kind of expected to see LinuxCNC drop out my E-Stop automatically if it wasn't happy.

And it's been a minute since I have done motion on an analog drive (1987 on a Berstorff calendar using a GE Series Six APM comes to mind).

tommylight wrote:

I hope this is a better explanation than the one above.

It was excellent! And thank you for your time!


John

Hi guys,

Okay, so I wired up a couple of relays for the enable interrupting the power (+24VDC) to the overtravel relays on the drives. One for each of them.

I added these two lines to the .hal file:

net z-enable => hm2_7i92.0.7i77.0.0.output-03
net x-enable => hm2_7i92.0.7i77.0.0.output-04

Which turns on the "enable" (or stops inhibiting the drives in this case) for each drive. This works as expected with the overtravel limits operating as expected with or without the drives enabled.

So, while the axis still drifts as before, it will now fault out with a following error at .05". This wasn't happening before adding the enable lines (they axis would continue to drift for as long as you let it prior to this change).

Another thing going on, and I missed this, is that the GUI E-Stop only drops out machine power, and not the E-Stop circuit. I was wrong in this.

What I see is wrong is that I used:

net estop-ext => hm2_7i92.0.7i77.0.0.output-00

instead of:

net estop-out => hm2_7i92.0.7i77.0.0.output-00

estop-out is driven by iocontrol.0.user-enable-out, which is an internal bit showing the status of the system. I don't know why this isn't on, or what the fault is.

I tried it with the .out bit instead of the .ext bit but the E-Stop wouldn't come on.

From the man page:

iocontrol.0.user−enable−out (Bit, Out) FALSE when an internal estop condition exists

So how do I find out what the internal condition is?

I have also read where this can be ignored, which allows the machine to be used. So this might not have any bearing on what is going on.

Here's the new .hal file, I made no changes to the .ini file:




Thanks again for all of your help!

John