Incorrect Axis Motion

Will do on the Notepad++.
As for the source pins, I have the following lines:
These lines are all below the net lines I listed in the above post but the device kind of works so I assume hal doesn't exactly read top to bottom? A question I have is about the meaning of the numbers after stepgen. I thought those related to the axis or port or something and tried changing the parport lines like this:
to this (changing the '0' to a '1'):
only to get errors. Also, is there anything else that needs to be done for source pins? So far, I think I've figured out there's a problem with the dir pins because the tool only moves towards one direction.

parport.1.xxxxxx would refer to the second parallel port (parallel ports are numbered 0,1,2,3 etc)

If you dont have two parallel ports or if the second port is not in output mode,
the pin parport.1.pin-04-out-reset would not exist, so you would get a error

The order of net commands does not matter

The numbers after stepgen are enumerations, that is how you separate one stepgen from another,
so if you had 3 stepgens for as 3 axis machine they would normally be numbered 0,1,2
They are commonly assigned
0 = X
1 = Y
2 = Z
but this is arbitrary

Turns out the code was OK. There was a misplaced jumper on the board that was causing problems. With that reset, the axes actually move normally again. Thank you all for the help!

On a separate note, does LinuxCNC automatically deal with homing and limit switches in their own unique way? I'm having an issue where the home switches act like limit switches though they are clearly coded as home switches. I get an error along the lines ofwhich I think is resulting from homing not happening before a limit switch is thrown so that'll probably be sorted when homing is.

Is it possible to hard-code an origin for the machine and have it return there every time it finishes up so that it doesn't have to home?

Thank you!