[ftec]

Where can I find enough information to understand the concept of homing with index and implementing it? Drives are VSD-A. Thanks.

[Xerxes]

There are only two parameters that sets homing with index:
-Use index pulse for homing: disabled, positive edge or negative edge
-Index search direction: positive or negative

So first define wich polarity pulse the encoder is outputting. In 99% cases its positive. Then just choose rotating direction where drive starts looking for index. If you choose positive, then drive will rotate motor to positive direction and stops at index pulse.

You might also want to use index with home switch or hard stop homing feature to make drive stop on correct revolution. You may also adjust homing speed from Trajectory planner page.

Its safe to experiment with settings if you set torque limits so low that hitting machine ends won't damage anything.

[ftec]

Ok, so one index pulse per rev. Can you tell how accurate this homing is? With rotational axis I don't feel like trusting external homing switches to get the angles right.

So, if I don't want to use homing switches at all I must power the machine off so that all motors are within the same revolution where I want them to be homed when power is turned on. Perhaps run them, say, a half rev away from the index home before turning the power off?

When power is turned on the homing obviously will start for all axis simultaneously. Can I control the starting of the homing with the Disable input (we have a separate Disable/Enable switch for each axis)?

If one axis dies is it possible to home only this one axis?

Thanks

PS. Is the hard stop homing feature you mentioned a feature in VSD-A? If so, how does it work?

[mactec54]

ftec
It is as accurate as your machine is Ballscrew Etc, & the same every time you home the machine

[ftec]

ftec
It is as accurate as your machine is Ballscrew Etc, & the same every time you home the machine

I meant accuracy within appr. how many encoder pulses. When homing with external switches you can expect the 0 point to be a little different each time. Definitely must be a lot better when homing with the motor axis itself.

What I'm after here is that once a rotational axis table has been aligned parallel to xy plane how accurately it will be parallel when homing with index or is a mechanical locking pin & adjusting still needed each time. (You can't answer this question for me though).

[mactec54]

ftec
I did answer your question,It will be the same every time, The encoder only has one Z pulse/index pulse, if using this your machine will be 0.0 everytime

[ftec]

ftec
I did answer your question,It will be the same every time, The encoder only has one Z pulse/index pulse, if using this your machine will be 0.0 everytime

Ok, I'll take your word for it then, sounds very promising. A short article of these extra homing features and how to use them would be good. They are mentioned on one line only in the manual.

[Xerxes]

For overview, there are two videos demonstrating drive homing in action:
http://www.youtube.com/user/granitedevices
Please read also video descriptions.

Ok, so one index pulse per rev. Can you tell how accurate this homing is? With rotational axis I don't feel like trusting external homing switches to get the angles right.

Repeatability is within one encoder count.

So, if I don't want to use homing switches at all I must power the machine off so that all motors are within the same revolution where I want them to be homed when power is turned on. Perhaps run them, say, a half rev away from the index home before turning the power off?

Yes, or use home switch/hard stop homing to do that for you.

When power is turned on the homing obviously will start for all axis simultaneously. Can I control the starting of the homing with the Disable input (we have a separate Disable/Enable switch for each axis)?

Yes, disable does that.

If one axis dies is it possible to home only this one axis?

What you mean by dying? Faulting? No need to re-home it, just enable drive and it goes back to position.

[ftec]

OK, that's it.

The hard stop doesn't seem like an option in our case though it looked pretty cool. Instead, I can see that defining the machine zeros just a few pulses off from the index home positions will work for this machine: I'll just run all the axis to machine zero when quitting for the day. Then, after the homing to index, the homing sequences will offset the axis back to the machine zeros. If I also mark the zeros approximately to be on the right rev it's easy to recover if power fails.

One last question at this point: The index wires are marked index+ and index-. Do both wires need to be connected to VSD-A or is the pulse measured against GND and only the positive or negative index wire is needed according to if it's negative or positive edge which is used? (I'm using BL servos).

[Xerxes]

The index input is identical to A and B channel inputs, so connect it same way than A & B.

[ftec]

OK, thanks.

I'll try to remember to give feedback of how it went but it'll take some time to make the new wirings and changes.

[ftec]

All four axes now have homing with Index and they seem to work perfectly and accurately. The positive Index Search Direction accepts negative values for Homing Offset so it was pretty easy to set the Homing directions the way I wanted.

The only negative thing I notice after playing with it a while was that if - and when - re-referencing with Mach position is needed the power must be turned off to start the Homing sequence. Currently I have no switches connected to the VSD-A Home inputs. Is it so that with NO panel switches connected to the Home inputs each drive could be homed when ever necessary and not only on power up?

[Xerxes]

Start of homing can be done two ways in VSD-A: on logic supply power-up or thru SPI bus. The power-up is the only practical way. VSD-E has additional inputs that can be used to initiate homing.

[ftec]

Start of homing can be done two ways in VSD-A: on logic supply power-up or thru SPI bus. The power-up is the only practical way. VSD-E has additional inputs that can be used to initiate homing.

OK, so the "Start Homing at power on" check box in the Homing Controller is intended for the SPI only and no tricks available there.

BTW, are all the motor tuning values - including acceleration - applied as set when the motor is moved back and forth from within GDtools? What I mean is that the motors run much smoother when run from within GDtools via SPI configuration cable than from Mach. Setup values which work properly during the setup process don't necessarily work as well with Mach and many times I had to change the values after testing them with Mach. There is even a noticeable difference in motor sound. Perhaps this has something to do with the Step pulse quality or do you have another explanation? The machine is running OK with Mach so no problem there, just interested to know what this might be.

[ftec]

Probaby relating to the last question in my previous post a weird thing happened the other day.

I have the acceptable following error set to 50 pulses in the VSD-A setup for all axes. This is OK in my woodworking hobby as it corresponds to an appr 0.04 mm allowable measuring error. Never did this limit value result Following Errors and probably the value could be even smaller but I have had no need to test how low one could go.

I then installed an AGP ATI VE display card in my Mach computer thinking it would free more resources for Mach to use if not using the OnBoard display system of the Intel Mother Board. What happened was that my heaviest X axis started to get Following Errors when ever Feed Rate exceeded appr 2000 mm/min. I then removed the card, all the relating drivers and programs and everything changed back to normal again.

Fixed error: was 2000mm/s should read 2000mm/min

[Xerxes]

I have the acceptable following error set to 50 pulses in the VSD-A setup for all axes. This is OK in my woodworking hobby as it corresponds to an appr 0.04 mm allowable measuring error. Never did this limit value result Following Errors and probably the value could be even smaller but I have had no need to test how low one could go.

I then installed an AGP ATI VE display card in my Mach computer thinking it would free more resources for Mach to use if not using the OnBoard display system of the Intel Mother Board. What happened was that my heaviest X axis started to get Following Errors when ever Feed Rate exceeded appr 2000 mm/min. I then removed the card, all the relating drivers and programs and everything changed back to normal again.

I bet you're using step/dir from parallel port? The ATI card probably causes some jerkiness or jitter in step pulse train which equals very fast accelerations. Following error is higher during jerks compared to smooth motion.

BTW, are all the motor tuning values - including acceleration - applied as set when the motor is moved back and forth from within GDtools? What I mean is that the motors run much smoother when run from within GDtools via SPI configuration cable than from Mach. Setup values which work properly during the setup process don't necessarily work as well with Mach and many times I had to change the values after testing them with Mach. There is even a noticeable difference in motor sound. Perhaps this has something to do with the Step pulse quality or do you have another explanation? The machine is running OK with Mach so no problem there, just interested to know what this might be.

You're right. The trajectory generator inside drive generates 'perfect' acceleration ramps without any jitter. The output from parallel port is rougher including jerks from system load. The SmoothStepper can be a good solution if this bothers much.