Confusion-please enlighten

Thanks, that clears some of the confusion. I'll be working my way through what you have explained. I am sure I'll still have more questions about pncconf and what it's various terms translate to. I'm still not clear what pins they are referring to in the port configurations, they don't seem to have any correspondence to the G540. What file and subdirectory provides pncconf with it's screen options and information?

Most of the "pins" I have mentioned are HAL "pins" not physical pins on the 5i25 or G540.

In Pncconf try choosing the prob_rxf2 board as the firmware. The physical pin layout won't match the G540, so ignore that, but the actual config will end up looking identical, with the different pin-mappings being defined by the firmware.

Is there any documentation or explanation that describes the relation ship between the numbers on the left hand side of these screenshots and the physical output pins of the DB25 (I/O Connection 3) on the 5i25? Perhaps a description that ties them into the
hal files or the ini? Does the halui: show pin or show param command give me the names of signals that are linked to physical pins?

Thanks things are a little clearer in terms of flow but still muddy is some details

It looks like the numbers are instance numbers for PWM and stepgens, etc
(stepgen 0 is stepgen 0 regardless of what pins it uses) and GPIO numbers for GPIO pins

If you look at a .pin file that corresponds to your current bitfile, it gives the translation between
GPIO and physical pin numbers, and also shows which pins are connected internally to
stepgens, PWMgens etc.

I think I understand but what really escapes me is how the stepconf generated parport outputs

setp parport.0.pin-02-out-invert 1
net xstep => parport.0.pin-02-out
setp parport.0.pin-02-out-reset 1
setp parport.0.pin-03-out-invert 1
net xdir => parport.0.pin-03-out
setp parport.0.pin-04-out-invert 1
net ystep => parport.0.pin-04-out
setp parport.0.pin-04-out-reset 1

corresponds to the pncconf generated

# ################
# X [0] Axis
# ################

# axis enable chain
newsig emcmot.00.enable bit
sets emcmot.00.enable FALSE

net emcmot.00.enable <= axis.0.amp-enable-out
net emcmot.00.enable => hm2_[HOSTMOT2](BOARD).0.stepgen.00.enable


# position command and feedback
net emcmot.00.pos-cmd <= axis.0.motor-pos-cmd
net emcmot.00.pos-cmd => hm2_[HOSTMOT2](BOARD).0.stepgen.00.position-cmd

net motor.00.pos-fb <= hm2_[HOSTMOT2](BOARD).0.stepgen.00.position-fb
net motor.00.pos-fb => axis.0.motor-pos-fb


# timing parameters
setp hm2_[HOSTMOT2](BOARD).0.stepgen.00.dirsetup [AXIS_0]DIRSETUP
setp hm2_[HOSTMOT2](BOARD).0.stepgen.00.dirhold [AXIS_0]DIRHOLD

setp hm2_[HOSTMOT2](BOARD).0.stepgen.00.steplen [AXIS_0]STEPLEN
setp hm2_[HOSTMOT2](BOARD).0.stepgen.00.stepspace [AXIS_0]STEPSPACE

setp hm2_[HOSTMOT2](BOARD).0.stepgen.00.position-scale [AXIS_0]SCALE

setp hm2_[HOSTMOT2](BOARD).0.stepgen.00.maxvel [AXIS_0]STEPGEN_MAX_VEL
setp hm2_[HOSTMOT2](BOARD).0.stepgen.00.maxaccel [AXIS_0]STEPGEN_MAX_ACC


Thanks
bill a.

The difference is that the parallel port outputs are the actual Step and Direction signals sent to the drive. The PNCConfig connections are position and velocity, feed-backs and commands communicated between Linuxcnc and the Mesa hardware. You never really see the true step and direction signals to the drives in a Mesa setup. In fact there are times when those signals could be far to fast for Linuxcnc to even reliably observe them, let a lone generate them.

That is why they look so different. (because they are different). The signals sent to the Mesa hardware are more analogous to the signals sent to the software step-generator in HAL, rather than what the step-generator sends to the parallel port.

I can see that there is more going on internally than determining which signal goes to which physical output bin. What I would really like to see is the hal command string that sends the X axis step signal to physical output pin 2 and the hal command string that sends the X axis direction signal to physical output pin 3.

is the command string " net emcmot.00.enable <= axis.0.amp-enable-out
net emcmot.00.enable => hm2_[HOSTMOT2](BOARD).0.stepgen.00.enable" analogous to the X axis step

and is "# position command and feedback
net emcmot.00.pos-cmd <= axis.0.motor-pos-cmd
net emcmot.00.pos-cmd => hm2_[HOSTMOT2](BOARD).0.stepgen.00.position-cmd

net motor.00.pos-fb <= hm2_[HOSTMOT2](BOARD).0.stepgen.00.position-fb
net motor.00.pos-fb => axis.0.motor-pos-fb" anagolous to the X axis direction

thanks
bill a

What I would really like to see is the hal command string that sends the X axis step signal to physical output pin 2 and the hal command string that sends the X axis direction signal to physical output pin 3.

There is no such HAL connection

As Todd mentioned, the step signal especially cannot be routed through HAL

The firmware determines which step/dir pin is connected to which physical I/O pin
That is why there are different bitfiles for different break out boards and integrated breakout+drives
like the G540 and the MX3660

The pinout listed with the
command

Shows the current FPGA firmwares physical pin assignment of
step generators, PWM generators, encoders, UARTs, etc

My terminology is probably wrong, but it seems that the string
" net emcmot.00.enable <= axis.0.amp-enable-out
"net emcmot.00.enable => hm2_[HOSTMOT2](BOARD).0.stepgen.00.enable"
which is found in the .hal file is a sort of command is it not?

The net command (well 2 net commands) links Linuxcnc motion controllers enable pin to the
hardware stepgens enable pin.

When the blah.blah.blah.stepgen.00.enable pin is high, step generation is enabled,
when low, step generation is disabled. This means linuxcnc can enable and disable the
stepgen based on machine state (estop, machine-on etc)

Note that these pins are virtual pins and have no direct relation to physical pins
( other than that particular net only affects stepgen 0 )

net commands are like an old time telephone plugboard and work like this:

net bluewire Phaser_on_Overload => Phaser_warning_sound_enable

This connects the source pin Phaser_on_Overload to the destination pin
Phaser_warning_sound_enable via the signal (wire) bluewire

The second token of the net statement ( bluewire ) is the signal and can have any name
( its just the "wire" that carries the signal so could have random names,
but they are typically given descriptive names for clarity )

The other tokens are sources and destination of signals

Normally you can have one source but any number of destinations, here's a statement with 2 destinations:

net bluewire Phaser_on_Overload => Phaser_warning_sound Phaser_warning_LED

Note that the => or <= or <=> are just for looks and have no logical function