Mori MV 35/40 retrofit

Yes, you can use a spare encoder for a MPG

If you unwire (in HAL) the index enable from the homing logic you can set index enable by hand with SETP, halmeter it and see if it gets cleared by index. If it gets cleared immediately at any position it may be that you have to invert the index polarity.

You can do this physically by swapping the Z and notZ wires or by setting the encoders index invert parameter in HAL

Just a little update.


The Mori made its first part in over a month on sunday. It is far from finished but is slightly functional.

The completed list.
1. Axis are all functional
2. pid error is in check under 50% rapid.
3. Tool pot magazine functions CW and CCW depend on shortest route to tool.
4. Tool change arm changes out tools
5. Home switches and limit switches function

The to do list
1. Make mounting board for control pannel. (curently using just using axis on the computer)
2. hookup inputs to 7i64
3. tweak hal file for inputs
4. get touchy up and running
5. figure out why homing index doesnt function
6. set software soft stops closer to limit switches
7. figure out a spindle encoder

Current Issues
1. When I try to instal the select_axis.comp i get the following error. I have atached the comp as a txt file

cory@cory-desktop:~$ sudo comp --install select_axis.comp
[sudo] password for cory:
Traceback (most recent call last):
File "/usr/bin/comp", line 1327, in <module>
main()
File "/usr/bin/comp", line 1296, in main
process(f, mode, outfile)
File "/usr/bin/comp", line 1170, in process
a, b = parse(filename)
File "/usr/bin/comp", line 404, in parse
a, b = f.split("\n;;\n", 1)
ValueError: need more than 1 value to unpack

2. Homing Index. I curently have the homing index turned off. The encoders are single ended so polarity should not be an issue. Ill try to do some more diagnosing on this tonight.

Thanks For all your help guys

Index polarity _is_ important regardless of whether the encoder signals
are single ended or differential, if its wrong, it will likely not work

Thanks Andy I just replaced it with a weighted sum and select8. I hadn't discovered the select8 comp yet.

Well the tipical one step forward two steps back technique.

I was working on tuning the servos a little better and i have pid.0.error down to +-.0002 runing and .0004 spike at motor start. (P=35 I=1000 D =.1 FF0=0 FF1=.11 FF2=0) This is during a 10" rapid move with a max velocity of 475 in/min and Max Acceleration of 20 in/s/s. do the value in halscope corespond to machine units? in this case inches?

The issue is when I turn the ferror and min ferror down to .005" and .001" I get a following error even at slow jog speeds.

Any ideas?

clkeck1 wrote:

Thanks Andy I just replaced it with a weighted sum and select8. I hadn't discovered the select8 comp yet.

Well the tipical one step forward two steps back technique.

I was working on tuning the servos a little better and i have pid.0.error down to +-.0002 runing and .0004 spike at motor start. (P=35 I=1000 D =.1 FF0=0 FF1=.11 FF2=0) This is during a 10" rapid move with a max velocity of 475 in/min and Max Acceleration of 20 in/s/s. do the value in halscope corespond to machine units? in this case inches?

The issue is when I turn the ferror and min ferror down to .005" and .001" I get a following error even at slow jog speeds.

Any ideas?

That is good. Now, you need to add just a LITTLE bit of FF2 to reduce the acceleration spike.
A little goes a long way, sometimes even .001 is all you need on FF2.

Yes, your displayed units in Halscope are user units, so inches and seconds (not minutes).

Are you sure that much I is helping?

MIN_FERROR is a floor for allowed following error. So, with MIN_FERROR = .001, then no error less than
.001" should ever trip a following error.

Ferror is a value that is proportional to speed in user units/second. So, at 120 IPM, an FERROR of .005
will allow an additional amount of following error of .010"

Given the above info, it seems you should NOT be getting following errors, if the spike never exceeds
.0004" Make sure the following error is actually happening on the axis you are working on, and not
a different axis. (Axis_0 is X, Axis-! is Y, etc.)

Jon

I worked on it a little more tonight.
(P=40 I=275 D =.12 FF0=0 FF1=.116 FF2=.0002)

I still have a following error issue the attached picture is with Ferror and min_ferror set to .005" The machine errored out on axis 0 (X) at 5in/s and .0001" error there was a .0002" spike at the begining.

This was with max feed set to 4.5 in/s and the same ferror settings and all was well.

clkeck1 wrote:

I worked on it a little more tonight.
(P=40 I=275 D =.12 FF0=0 FF1=.116 FF2=.0002)

I still have a following error issue the attached picture is with Ferror and min_ferror set to .005" The machine errored out on axis 0 (X) at 5in/s and .0001" error there was a .0002" spike at the begining.

I wonder if you have too much I? Other than that spike at the start, everything looks very good.
Even the spike is not bad, it is only .0002" (4 divisions at 50 u"/div). I also notice a static error
of about 1 division (those square "boxes" just before the move starts. Unless your encoder
resolution is 50 u", then it is just the position quantization inherent in the encoder. But, maybe
when there is a move, the integral term gets dumped and causes a discontinuity. I have never
seen an EMC system where I was more than 20% of P, so I'm just suspicious.

Jon

Encoder resolution is 40u".

I will pull some more I out and see what happens. It seemed like it wanted more to balance out. With less it went from high to low or low to high. I dont know that I tried anything that low thought. I was under the impression I was 100 plus term.