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.

@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"...

I see that the question posed in the Subject: has been amply answered[1]. I don't want to pollute the thread more with further questions about my particular config.

I'll start another, probably by begging...

[1] It's, only, in the pinouts list generated by:
mesaflash --device <boardname> --readhmid
In PnCConf, three-digit numbers are GPIO numbers, one-digit numbers are channel numbers.

As tommylight says, those pins (with secondary function=none)  can be outputs (or inputs)

Even pins that have a secondary function can be used as GPIO (either input or output) if the
secondary function is disabled in hal. For example, in the DMMBOB config, the encoder pins
(DB-25 pins 11,12,13) are available as inputs but if you disable the encoder in the hal file,
they become available as outputs also.

Basically all pins have GPIO capability (on all Mesa FPGA cards and all hostmot2 configurations).
If a pin has an _enabled_ secondary function the, GPIO capability of the pin is lost as the secondary
function takes control of the pin.

For example if you specified (num_stepgens=0 num_pwmgens=0 num_encoders=0) with the DMMBOB
configuration, all pins would revert to GPIO, with any pin be assignable as an input or output.
 

I am returning to my quest to configure a new Mesa 6i25 (PCIe variant of Mesa 5i25) to work with my existing wiring, for which I have configuration information available in the .stepconf file. (I am constantly being batted from pillar to post--the latest distraction was dealing with 70-something locust tree I felled on one of my sheds while attempting to "protect" it from same... :eyeroll:) Each time I am able to return, I face another bout of "re-education." I am sorry for being so dense.

I flashed (and --reloaded) the 6i25 with 5i25_5ABOBx2.bit to get a PWM on pin1, and stepgen/dirs on 2/3, 4/5, 6/7, 8/9.

In PnCConf, I selected Board Name 5i25 and Firmware 5i25_5ABOBx2 and then set "Num of encoders, Num of pwm generators, Num of step generators" to "0,1,4" and Accepted Component Changes.

The original qd1212xyz.stepconf is attached. [TLDR: pin 1: spindle-pwm-inv pins 2/3: xstep-inv/xdir pins 4/5: ystep-inv/ydir pins 6/7: zstep-inv/zdir pins 8/9: astep-inv/adir pin 11: probe-in-inv pin 12: home-x-inv pin 13: home-y-inv pin 15: home-z-inv pin 17: spindle-enable]

(Of the attachments, lower-case names indicate the old, parport-/software-stepper configuration; UPPER-CASE signifies the new, Mesa-5i25/6i25 configuration.)

I have also attached the corresponding qd1212xyz.hal, from the same software-stepper approach, and QD1212XYZ.HAL, the .hal intended for the 6i25, edited to match, I hope, the pinouts found in qd1212xyz.hal.

I'm also attaching screenshots from PnCConf, showing the choices I made.

If anyone has time to comment, please do.  In particular, if you'll pardon my obsession with the topic, why is the information about which DB25 pins the step-generator signals occupy not shown in PnCConf? And why aren't some DB25 pins listed; for example, pins 11, 12, and 17, which I need for my setup? It bothers me that I'm changing pin assignments in .hal that are not listed in PnCConf.

(I am very fearful of blowing up the electronics in the CNC by mis-configuration, creating yet-another emergency, and one I might never live to see repaired. That is why I want very much to understand what I'm doing.)

Anyway, I'm happy to have this out there for you to look at, and I'm still grateful for all the help. Thank you. I will continue plodding.