A Treatsie on the Parallel Port - HP Elitedesk 800 with generic cable

Sorry I missed the bit about the lathe axis.
Also regarding the enables.
This thread on cnczone maybe of use.
www.cnczone.com/forums/stepper-motors-dr...14207-schematic.html
Oh and comletely missed the bit about the 6040.

Geesh I'm having a bad day with my reading, writing & comprehension of Engrish. I would have edited the previous post but the editor is a real PITA. I really apologise for being such a dill.

I found a site that describes how to make a generic cable (not the expensive HP one) work. Plug the cable into the PAR connector on the motherboard. On the other end, remove the two nuts and slide the plastic sleeve back. The pins will be exposed. If you look carefully at the connector holes (magnifying glass...) you will see they are numbered. Join pin 21 and 25 using a jumper wire. That's it - the port will appear in the BIOS, but it should already be working with no other config needed

Yes, the deal is this. I found a guy with a "new" in the box 6040 with 4th axis lathe attachment for $400US, bought a desktop PC to drive it for $40 and the StarTech LPT board for $20.

This wasn't my first choice, it was just an opportunity that presented itself and I thought I'd try out a router because I was thinking of building a PrintNC. A coworker recommended LinuxCNC. I keep wondering why people aren't just running these things off a 3D printer board running Klipper or a slightly modified Klipper... seems like a better option overall than these parallel port controllers.

Obviously everything is a bit questionable, the router is probably underpowered, there are no endstops or position feedback. I can imagine skipping a step really screw you up. But for $500? Meh...

Now if only I could figure out how I screwed up my install and why when I try to reinstall off the USB key it keeps complaining there's an error while trying to create the main ext4 partition.

Thanks for the feedback on the schematic, that was my read as well, I just was unsure what the controls were called on LinuxCNC/stepconf

Linuxcnc is miles ahead of what is running 3D printers.

I've been running my 3 axis mill for years with no limit, homing switches or position feedback, the parts come out fine.

Without seeing the actual error it's hard to tell. I'd just boot into a live session and use fdisk to remove the existing partitions and try the installer again.

If you are unsure about anything, and I'm going to be that guy, the documentation is there, full of information. The devs spend time writing them, so give them a read, even after all these years I still read them.

After playing around with it forever, I was able to reinstall LinuxCNC from scratch and loaded the driver (the parallel port card already seemed to be enabled).

I tried configuring as:

Pin 1 = EStop On
Pin 2 = A Step
Pin 3 = A Dir
Pin 4 = Y Step
Pin 5 = Y Dir
Pin 6 = Z Step (I think you swapped Pins 6 and 7 in your writeup)
Pin 7 = Z Dir
PIn 8 = EStop On
Pin 9 = Estop On
Pin 14 = EStop on
Pin 16 = X Step
Pin 17 = X Dir


I'm not sure what Enable is supposed to be on LinuxCNC. In order to send manual commands from LinuxCNC it seems like I have to toggle the Emergency Stop and then Machine Power.

That said, when I went to check the outputs on a scope, it seemed kind of weird. Pin 1 was high all the time, but Pins 8, 9, and 14 were low. I tried putting "invert" on all 4 pins, and they all read low. So I suspect there is still an issue outputing out of the parallel port.

This time, unlike last time, the only axis that "worked" was Y. Previously, with the default setup Z clearly worked perfectly (possibly with the opposite orientation). When doing Y+, the motor put out a motor-like hum, and I saw the leadscrew turn, but it didn't seem to move super smoothly. When going the opposite direction,the leadscrew moved around faster, in the opposite direction and with some awful noises.

Try the parallel port tester as mentioned at the beginning of this thread.
Try it without the breakout board connected, if everything is fine try again with the breakout board connected.
BTW what voltage are you powering the breakout board with ?

I think a look at your hal and in files will need looking at. And a drawing of your actual wiring.

I couldn't get the parallel port tester to work (as in it complained about a ton of Python code when I executed it, and I did modify the port from 0x378 to 0xd010 in ptest.hal). When I said:

"That said, when I went to check the outputs on a scope, it seemed kind of weird. Pin 1 was high all the time, but Pins 8, 9, and 14 were low. I tried putting "invert" on all 4 pins, and they all read low. So I suspect there is still an issue outputing out of the parallel port."

I meant I had the cable plugged into the computer but not the controller and had an oscilloscope on the pins. It is of course possible the cable is not fully populated with wires or that the wires are twisted. I find it interesting that with the default configuration the Z axis seemed to work, and I think the only difference was that the enable signal for it was "A Step" and the new one is "EStop On". So perhaps Pin 8 on the cable isn't Pin 8 on the port. I'll try to ohm out the cable and establish continuity across the pins.

Given that I never saw Pin 8 go high (at least in the configuration you gave me), I think it's unlikely the controller is to blame.

As a side note, for reasons I don't understand I seem to still have to uninstall and reinstall parport_pc.ko after each reboot to get the port back.

Sadly, it doesn't look like it's the cable. Multimeter says all pins are connected and not twisted (I didn't exhaustively ook for internal shorts, maybe I should check that, but seems unlikely).

I'll try the default configuration file and see if Z axis functionality is restored and then compare the files.

On a lark, I tried something... I created a new profile for XYZ and a second new profile for XYZA (I think I also set the XYZA one to mm, whereas I forgot and default to inch for XYZ).

Amazingly, on the XYZ profile, Y and Z worked perfectly, X didn't work at all. This isn't a shock because the default values for X put it onto my A. So I hand edited the HAL file, and changed X to be on pins 16 and 17, and...

EVERYTHING WORKED!

So basically, at this point, I think I have a working system and just need to tune the .hal and .ini files (or learn how to do it). When I looked through the original file I had generated ESTOP_ON was ONLY on pin 1, not on 8, 9, and 14 -- so that explains why they never went high.

Thank you so much for nailing the problem in one comment, PCW!
Thanks for sticking around and constantly pointing me toward the finish, Cornholio!