How do PnCConf's Mesa Card 0 I/O tabs' pin numbers correspond to stepconf's?

Q1. How does the "Num" field numbering on PnCConf's Mesa Card page/IO P3's tab correspond to the DB25 output pins?
  For example, which DB25 pins will "Nums 0:, 1:, 2:, 3:" appear on?

I am trying to bring up a Mesa 6i25[Note 00 below] in a former software-stepping-to-parallel-port set up. 

I'm running LinuxCNC 2.8 and have a "Chinese BOB" (picture attached).

I am proceeding at a snail's pace because a) people aren't breathlessly awaiting my product, b) I have other similarly mysterious projects that take time, and c) I'm fearful that connecting the parport cable without complete understanding risks the two endpoints blowing each other up, and d) my brain.

After much reading and a window of clarity, I finally flashed the dmmbob1x2[0] firmware into the card's EEPROM[1] and reloaded the FPGA[2] and confirmed the pinouts[3].

I used PnCConf to create a New Configuration (screenshot attached).

As I've re-opened the configuration in PnCConf to re-familiarize myself with it, I cannot see how its numbering corresponds with the pin assignments my BOB expects[4]. For example, the PnCConf screen has both single- and triple-digit numbers and has, in my case, duplicate TWO "0:"s and BOTH "001:" and "1:" "Num"s.

Triple-digit numbers appear to correspond directly with .stepconf's pin numbering, although there is no "017:" for me to define as a "spindle-on" output.

Single-digit numbers are all "Gens", "PWM Gen" and 3 "Axis StepGen"s, so I take it these numbers refer to signals being provided by the Mesa card, off-loading that responsibility from the motherboard cpu.

BUT, on which pins will these show up on the DB25 port?

"ESTOP In" is another mystery.  I don't even find it among the pins listed in the .stepconf file, and I cannot now figure out how it was enabled, except for a commented-out line in one .hal file, reading:
"#net estop-out => parport.0.pin-01-out # stepconf created;verified that 01 is spindle"
The same .hal went on to specify:
"net estop-out <= iocontrol.0.user-enable-out"
"net estop-out => iocontrol.0.emc-enable-in"
which is what all other .hal file examples I have contain.



NOTES:
[00] The 6i25 is the PCIe bus variant of the PCI-based 5i25 card; functionally the same.
[0] Actual file was "5i25_dmmbob1x2.bit" from Mesa's 5i25.zip download. 5i25_5ABOBx2.bit is another candidate.
[1] sudo mesaflash --device 5i25 --write 5i25_dmmbob1x2.bit
[2] sudo mesaflash --device 5i25 --reload
[3] sudo mesaflash --device 5i25 --readhmid
[4] The pin assignments extracted from the working .stepconf file were:
pin1    spindle-pwm
pin1inv True
pin2    xstep
pin2inv True
pin3    xdir
pin3inv False
pin4    ystep
pin4inv True
pin5    ydir
pin5inv False
pin6    zstep
pin6inv True
pin7    zdir
pin7inv False

pin11    probe-in
pin11inv True
pin12    home-x
pin12inv True
pin13    home-y
pin13inv True

pin15 home-z
pin15inv True

pin17    spindle-on
pin17inv False 

I did find the attached table in the Mesa 6i25 Anything I/O manual, but I cannot make out how it relates to the numbers in the "Num" field in PnCConf.

I think the "function" number is what you can cross reference with.

function 0 on the PnCconf tab is Spindle PWM and  function 0 on the DB25 is pin 1 (PWM 0)
functions 9&10 on the PnCconf tab are Z Axis Stepgen and  functions 9&10 on the DB25 are pin 6&7 (StepGen 2)
function 11 on the PnCconf tab is Probe In and  function 11 on the DB25 is pin 8  (GPIO 11)

@phillc54, thank you for that observation. It makes sense if PnCConf's "Num" is the same as "FUNCTION" mentioned in the (Mesa 6i25 Anything I/O board) documentation, and is better than anything I had.  Note however that the screen capture of PnCConf's I/O Connection 3 tab shows TWO "Num 0:":
 
the first associated with "Spindle PWM" and the second with "X Axis StepGen".  By your observation both would be appearing on DB25 Pin 1.

I hasten to acknowledge that that might be a clear indication (to someone at least) of a corrupted firmware. (I do remember seeing some way to verify firmware, but I don't know what the verification metric is.)

For some reason, I am reminded of Red Skelton's story of driving across the vast flats of West Texas with his wife where nothing stood out as a landmark. After hours of seemingly making no progress, his wife finally asked him, "What's that over there?" He answered, "The horizon..."  She then told him, "Well, make for that; it's better than nothin'." 

My gut's telling me you're probably right, and my logic is telling me the config has to be wrong.

Thank you for giving an interpretation.

The "Num" column of pncconf is confusing because it's used for two separate numbers:

1. The function or module number (Stepgen 0 and PWMgen 0 in the screenshot)

2. The GPIO number (001 and 003 in the screenshot)

Its perfectly legal to have many different modules with the same number
but there is only one instance of specific GPIO numbers.

This would be much clearer if pncconf had separate columns for
module numbers, GPIO numbers, and pin numbers.

The actual pin number <=> GPIO correspondence is listed by mesaflash's --readhmid function
 

Thank you, Peter.

My --readhmid, as flashed with DMMbob1x2 firmware, follows.  I think I see, now, that it's going to be a non-starter for me.

Pins 15 and 17 are shown with "Sec. func" of "None", but my working .stepconf (given previously) wants pin15 as home-z Input and pin17 as spindle-on Output.

I'm guessing that makes this dmmbob1x2 firmware a non-starter for my setup.  Looking at my .stepconf again, I suppose I'm looking for a configuration that has:
1 PWM
4 stepgens (for future-proofing)
4 inputs (3 home + probe)
1 output (spindle on)
and give up on trying to match the current wiring.

Actually, the dmmbob1x2 "just almost" fills this bill: four pins, 14-17, have no assigned "Pin Dir".
"If Only"...