7i96s Questions

That looks OK

Where things go bad with bare FPGA inputs is that say a VFD is running and an encoder wire connects
to frame ground accidentally, well unfortunately this frame ground has ~1 usec 1V negative high current
spikes  from the VFDs 350V square wave output and finite inductance of the frame ground to earth ground.
These spikes will easily short the input clamp diodes. ("Ground" is just a tapped inductor for high frequencies)

The encoder pin/parameter specifications are in the hostmot2 manual page:

man hostmot2

It may be that firmware that better matches your application can be made
(MPGs are better with MPG encoders rather than motion encoders because
MPG encoders support 1X mode which works better with MPGs having detents)

 

PCW wrote:

It may be that firmware that better matches your application can be made
(MPGs are better with MPG encoders rather than motion encoders because
MPG encoders support 1X mode which works better with MPGs having detents)

 

Interesting, I have some MPG style encoders on order, I suppose I can look into this when they arrive.

After looking at the TVS's I put on my little daughter board I came to the conclusion that they were not going to help (not Schottky and Vmin specified as -0.3V) so I replaced with actual digital isolators. Presently the first two P1 encoders are routed to my scale encoders and the next two for MPG's.  So before I hit the send key can I assume that if a version with MPG friendly logic is available it will map the MPG encoders to P1 pins 7-13 or would they move to pins beyond the as is 4 encoders (P1:1-15), it would be easy for me to move my MPG inputs down to say IO:46-49 so they don't interfere with the original 4 encoder inputs if that make sense?
 

 

The P1 pinout can be random, it's completely determined by the PIN_XXX file.
(take a look at the source file include in the zip)

The only real pinout limitation is that modules like encoders or stepgens
are enabled by total number (num_stepgens=3 for example) rather than
individually, so you cannot trade off these pins for GPIO on a pin by pin basis
at runtime in hal. This is not actually a hardware limitation but just a choice 
made to simplify the driver command line.

PCW wrote:

The first P1 encoder is  encoder 1 so the position would be:

hm2_7i96s.0.encoder.01.position

and the most important parameter for that encoder would be:

hm2_7i96s.0.encoder.01.scale

 

Update, I received and populated my isolating board that plugs into the P1 connector of the 7i96s, I connected the Z scale and when I move Z, I can see the A & B quadrature data changing in PI-1 (io34), and P1-2 (io35), so looks like the data is making it to the FPGA.

However I can't see anything P1 related in HAL, and when I try to connect net "hm2_7i96s.0.encoder.01.position" to a net I get
postgui.hal:21: Pin 'hm2_7i96s.0.encoder.01.position' does not exist

So I'm doing something wrong.

Help please.
 

Do you have more than one encoder enabled in the hal file?

PCW wrote:

Do you have more than one encoder enabled in the hal file?
 

That was the problem.
I simply changed the count and now I can see the new encoder.

I think I'm away to the races.

Big Thanks