Convert from Anilam Crusader M to EMC 2

ryankracht wrote: Guys, I will address this question to the Mesa guys, unless you have this information readily available, but why is 5i23 / 7i33 more adaptable?

PCW is the Mesa guy. I just write some of the drivers.
Because the 5i23 has more pins, you can attach more stuff, and a bigger variety.
There are resolver boards and brushed/brushless/stepper motor boards that connect directly to the 5i23 style FPGA cards.

Why the 5i25 / 7i77 if I will never use 6 axis, why not 5i25 / 7i33?

You can't connect a 7i33 to the 5i25. The 5i25 has a 25-pin D-sub connector, and the 7i33 has a 50-pin box header.
(actually, with the right adaptor cable it could probably be made to work, but would need special firmware).

andypugh wrote: The 7i77 has the option to use some pins as low-resolution analogue inputs.

Ok. Does the 7i33 have that option as well?

or am I better off using a 3rd board dedicated to A/D for a high resolution conversion?

andypugh wrote: The 5i25 / 7i77 combo might work better for that conversion now, though the 5i23 / 7i33 setup used there is still good and potentially more adaptable.

My thoughts are that the 5i25/7i77 seems like it meets my requirements to bring in my glass scales (encoders) and output the +/-10V back to the drives, Andy references that the 7i77 will give me the ability to bring in the tachs as well, so I am not sure what other flexibility I would need. Any other thoughts on why I should still consider the 5i23 / 7i33?

ryankracht wrote: Ok. Does the 7i33 have that option as well?

Not as far as I know.

or am I better off using a 3rd board dedicated to A/D for a high resolution conversion? It would work better, I think. The 7i87 is 12-bit and can plug into a 7i77. That gives you 8 +/- 10V inputs which sounds fairly well suited for reading tachometer inputs. That would measure as little as 2.4mV up to 10V, whereas the ones on the 7i77 board are 8-bits and so read from 13mV to 3.3V (and possibly not very well)

If the tachos are 3V / 1000rpm then the 7i87 will measure 0.8rpm to 3300rpm, whereas the 7i77 built-in Analogue will only be good for 4.3 rpm to 1100rpm.

Take advice from Pete / Mesa before buying though.

ryankracht wrote: Ok. Does the 7i33 have that option as well?

Not as far as I know.

or am I better off using a 3rd board dedicated to A/D for a high resolution conversion

? It would work better, I think. The 7i87 is 12-bit and can plug into a 7i77. That gives you 8 +/- 10V inputs which sounds fairly well suited for reading tachometer inputs. That would measure as little as 2.4mV up to 10V, whereas the ones on the 7i77 board are 8-bits and so read from 13mV to 3.3V (and possibly not very well)

If the tachos are 3V / 1000rpm then the 7i87 will measure 0.8rpm to 3300rpm, whereas the 7i77 built-in Analogue will only be good for 4.3 rpm to 1100rpm.

Take advice from Pete / Mesa before buying though.

Next, I plan to confirm that all limit switches are still present in the circuit, and test the x and y axis as well. Finally, I plan to generate a reference signal and attempt to move all axis.

My goal during this upgrade will be to use all existing hardware. It appears that no-one has successfully done this, but I don't know why this shouldn't be possible. Anilam had a functional control after all. From reading other posts, my understanding is that drives get a tach feedback, and the motion controller gets (relatively low resolution) position feedback from "glass scales". I know of one successful Anilam to EMC via PPMC, although he had to add rotary encoders. I would like to avoid this, or at least understand why my current set-up won't work.

I am open to various motion control options at this point, my preference would go to whatever can drive my current hardware most efficiently for a reasonable cost.

Update on Progress:

- Confirmed function of all limit switches (single switch per axis--activated by dual fixed cams...one on each end of travel of the axis)...Done. E-stop will not reset if limit switch is tripped, system will e-stop if limit is reached while running.

- There is a spare terminal (P8) on the Anilam PCB 803 (see pic). If you bring pin 13 to gnd (pin14), the servos will enable upon e-stop reset. I wired in a momentary switch to this terminal so that I could keep my finger on a "deadman switch" while testing.

- Confirmed power up of all drives...done. There is no drift to the z axis, but some small very slow drift to the x and y.

- wired a 9V battery (see pic) to provide a 0 to ~3 V signal into the drives. To do this, I used pins 1-6 of the same terminal (P8) of PCB 803. I also needed to pull the connector from the Anilam control board that was outputting voltage. (PCB 502) Confirmed that I can drive both directions and stop. Done. Interesting that I can get rid of the small drift on x and y by applying a small control voltage. (seems like a good sign). I confirmed that positive voltage to the red wires give positive axis movement (from tool reference)

- checked tachs by measuring voltage across wires. I was surprised that this worked with the power off. I attempted to crank the axis as fast as I could, but I imagine that this is not as fast as they used to move when the controller worked. I measured about 5V max on the x and y, but saw up to 10V on the Z. The Z appears to have much more reduction, so I believe I could get the motor spinning faster with the mechanical advantage that I could use on that axiz. I am concerned that a 0-10V analog input is not a large enough range. I would not be surprised if the tach's output 0-15V like the signal input to the drives. If no 0-15V input is available, I will likely have to step down the voltage to make use of what is available. There is no convienent way to get this signal out as the tach's go directly into the drive. I needed to stick probe wires into the back of the connector to measure. TODO: confirm that the drive wasn't affecting this signal, unplug the connector and test again.

- I was surprised to see that with the axis moving in a positive direction (from tool reference) the tach sent a negative voltage.

ryankracht wrote: - checked tachs by measuring voltage across wires. I was surprised that this worked with the power off. I attempted to crank the axis as fast as I could, but I imagine that this is not as fast as they used to move when the controller worked. I measured about 5V max on the x and y, but saw up to 10V on the Z. The Z appears to have much more reduction, so I believe I could get the motor spinning faster with the mechanical advantage that I could use on that axiz. I am concerned that a 0-10V analog input is not a large enough range. I would not be surprised if the tach's output 0-15V like the signal input to the drives. If no 0-15V input is available, I will likely have to step down the voltage to make use of what is available.

You probably need bipolar reading A to D to sense the two directions. the 7i87 is safe to 100V so it might well not matter if the speed input tops-out during fast moves. The suggestion to use the tachs is purely to aid tuning at very slow movement rates.
Normally the PID loop calculates its rate of change by differentiating encoder position counts, which for a relatively coarse feedback system like your glass scale may be rather noisy.
Wiring the tach signals to the pid.N.feedback-deriv pins gives the PID controller a much less noisy and more accurate velocity input.
Note that the inut to this pin is only used for the D-term of the PID, so you will not see any benefit from it with no Dgain.
Whether $99 for the 7i87 is worth the investment is a choice you need to make, but I think it should really help to reduce dither between scale counts.
Other conversions have tended to add encoders to the motors, but this is probably even more expensive.
I think that the encoder conversion bases P and D on the motor encoder and I on the scales.
The proposal here would be to base P and I on the scales and D on the tach/7i87.
But I am aware that I am performing a thought experiment with your money here.

I was surprised to see that with the axis moving in a positive direction (from tool reference) the tach sent a negative voltage.

This is a non-issue and can be solved in HAL.
It is probably deliberate, the driver scheme is probably very simple, where the command voltage and tach voltage are summed, amplified and sent direct to the motors.