Mesa 7I52 with 3x20/7I68

Great I will confirm the IO allocation for P5.

With testing the step + dir on the 7I52S will homing all axis in LinuxCNC then issuing an M3 Sxx be sufficient to see pulses with a cro?

--- Additional, dmesg shows IO pins 0 and 23 are on P4? Physical pins 1 and 47 on P5 of 7I68 are high whereas corresponding pins on P5 are low.

hm2/hm2_3x20.0: 144 I/O Pins used:
hm2/hm2_3x20.0: IO Pin 000 (P4-01): IOPort
hm2/hm2_3x20.0: IO Pin 001 (P4-03): Muxed Encoder #0, pin Muxed A (Input)
hm2/hm2_3x20.0: IO Pin 002 (P4-05): Muxed Encoder #0, pin Muxed B (Input)
hm2/hm2_3x20.0: IO Pin 003 (P4-07): Muxed Encoder #0, pin Muxed Index (Input)
hm2/hm2_3x20.0: IO Pin 004 (P4-09): Muxed Encoder #1, pin Muxed A (Input)
hm2/hm2_3x20.0: IO Pin 005 (P4-11): Muxed Encoder #1, pin Muxed B (Input)
hm2/hm2_3x20.0: IO Pin 006 (P4-13): Muxed Encoder #1, pin Muxed Index (Input)
hm2/hm2_3x20.0: IO Pin 007 (P4-15): IOPort
hm2/hm2_3x20.0: IO Pin 008 (P4-17): IOPort
hm2/hm2_3x20.0: IO Pin 009 (P4-19): IOPort
hm2/hm2_3x20.0: IO Pin 010 (P4-21): Muxed Encoder Select #0, pin Mux Select 0 (Output)
hm2/hm2_3x20.0: IO Pin 011 (P4-23): IOPort
hm2/hm2_3x20.0: IO Pin 012 (P4-25): IOPort
hm2/hm2_3x20.0: IO Pin 013 (P4-27): IOPort
hm2/hm2_3x20.0: IO Pin 014 (P4-29): IOPort
hm2/hm2_3x20.0: IO Pin 015 (P4-31): IOPort
hm2/hm2_3x20.0: IO Pin 016 (P4-33): IOPort
hm2/hm2_3x20.0: IO Pin 017 (P4-35): StepGen #2, pin Step (Output)
hm2/hm2_3x20.0: IO Pin 018 (P4-37): StepGen #2, pin Direction (Output)
hm2/hm2_3x20.0: IO Pin 019 (P4-39): StepGen #1, pin Step (Output)
hm2/hm2_3x20.0: IO Pin 020 (P4-41): StepGen #1, pin Direction (Output)
hm2/hm2_3x20.0: IO Pin 021 (P4-43): StepGen #0, pin Step (Output)
hm2/hm2_3x20.0: IO Pin 022 (P4-45): StepGen #0, pin Direction (Output)
hm2/hm2_3x20.0: IO Pin 023 (P4-47): IOPort

Its likely that the driver dmesg data does not match the 7I68 pinout
I will look into this tomorrow

You will be able to see step/dir pins toggle bu note tha the sample config is a step/dir config with encoder feedback
so if the input scale and output scale do not match the hardware, you will get and instant following error
if you try to move (unless you widen the ferror and min_ferror limits)

Actually the dmesg is correct about P4

I must have fixed the source(7i68.ucf) at some point but did not update the 7I68 manual

So the pinout is somewhat rational:

Left side
P4 GPIO 0..23
P5 GPIO 24..47
P6 GPIO 48..71

Right side
P9 GPIO 72..95
P8 GPIO 96..119
P7 GPIO 120..143


I have updated the 7I68man: www.mesanet.com/pdf/parallel/7i68man.pdf
to reflect the fixed 7I68 pinouts

Great what I see on the board is P4-1 and 47 low, all other header pins of the same number are high.

Updated the .ini file with some larger values for ferror and min_ferror, however following error comes up straight away. Encoder on the drive (Delta) appears to have 1,650,000 ppr.

Should these be arbitrarily large numbers? >100

--- edit
> 10 solved the issue, step pulses now seen, thanks

1,650,000 PPR is not possible to relay as a quadrature signal

The drive must have a way to set the resolution of its quadrature output
and its likely to be less than say 32000 counts/turn

For a stepgen/encoder feedback system to work you need the
output_scale to be steps/machine unit and the
input_scale to be encoder counts/machine unit
from the drive.

and of course it helps if the encoder and stepgen directions match

Delta drive has a user adjustable parameter, have configured this for 2500ppr

I do have encoder feedback and can drive with say G0 X1, albeit with following errors, however no change to the DIR line when a G0 X-1 is issued.

Are there any checks i can perform on the DIR (TX0A)? Does the FPGA drive this line solid in the required state, for the duration of the step/movement or pulse in some other fashion?

Using the 7I52 as line driver to the drive controller. No change to the DIR output when the Delta drive input is disconnected and the DIR output scoped.

I would not necessarily expect the direction to change unless the feedback loop is working

This requires:

1. That the step/dir scaling and encoder feedback scaling are identical and in the same direction
2. That the ferror and min_ferror setting are wide enough to let the drive to follow without an immediate following error

debugging this will require probably require widening the ferror limits and
looking at the encoder position and the PID output (via halmeter for example)

Thx Peter

I missed the step type that was default in the example HAL file, hm2-encstepper.hal

setp hm2_[HOSTMOT2](BOARD).0.stepgen.00.step_type 1

Changed to step + dir. Now have direction.

setp hm2_[HOSTMOT2](BOARD).0.stepgen.00.step_type 0

First servo is running nicely so second has been connected. Cro verifies step and direction are being generated for second servo.

Issue is I cannot see the #1 encoder counts in LinuxCNC on the pins below:

hm2/hm2_3x20.0: IO Pin 004 (P4-09): Muxed Encoder #1, pin Muxed A (Input)
hm2/hm2_3x20.0: IO Pin 005 (P4-11): Muxed Encoder #1, pin Muxed B (Input)
hm2/hm2_3x20.0: IO Pin 006 (P4-13): Muxed Encoder #1, pin Muxed Index (Input)

The 7i52S manual shows a pin "21 ENCMUX TO 7I52S", does this need to be configured in some manner?

Delta servo's have been swapped so can confirm these devices are running. Encoder ABZ are making it to the 7i52S, changing state, and all jumpers are configured for TTL.

Are you saying encoder input 1 does not work, that is it does not count?

(encoders 0 and 1 use muxed encoder pins 0)

You will not be able to read any meaningful signals from the muxed encoder pins (that is if you look at the equivalent GPIO pins).

LinuxCNC master has code that allows watching the A,B,Z signals of a muxed encoder