No input signals w/ AsRock Q1900M onboard parport

Hey guys.

I recently purchased an Asrock Q1900M motherboard for my control PC. It's attached to a Leadshine MX3660 driving a 3-axis G0704 conversion. Latency is low and I've been happy with LinuxCNC 2.6 installed via the live Wheezy ISO. I have been unaffected by any of the USB issues previously reported w/ the J1900 motherboards. Unfortunately, I cannot see any input signals via HAL through the onboard parallel port. Outputs are fine and I have reliable 120 ipm rapids.

When I load the ptest.hal application on the Q1900M, all pins are red. Clicking on outputs such as pins 2 and 3 give me 0-->3.3V with a multimeter attached between the output pin and ground. If I short input pins such as 10 or 15 to ground, no ptest pins turn green. I have a separate HP laptop with a parallel port on the docking station and ptest runs as expected. The app starts with several input pins green (active low). When I short pins 10 or 15, the pins turn red as expected. I'm not quite ready to fault the Q1900M hardware or BIOS settings, however, as running a parallel port test app unrelated to LinuxCNC seems fine. You can download the app at yyao.ca/projects/ParallelPortLinux/. I can boot the live ISO, apt-get install freeglut3-dev, make the tool, run it and hit "space" to toggle into read mode. Once here, shorting pins 10 or 15 show me a green LED, similar to what I would expect to see from ptest. I have also confirmed that the pin 15 e-stop and limit switches on pins 10 - 12 trigger the green input on the ParallelPortLinux app when my MX3660 is attached to the Q1900M parallel port.

I initially disabled all power saving features in the BIOS and ran with the factory version. Later I updated to BIOS 1.50, reset to factory settings and tried a wide array of parallel port modes and addresses such as normal, bidirectional, EPP 1.7, EPP 1.9 as well as auto-addressing, explicit 0x378 irq 5 and 0x278 irq 5 addressing (making the ptest.hal changes accordingly when not using 0x378). I've also tried running LinuxCNC without the lp, ppdev, parport and parport_pc kernel modules loaded. If I recall, I did have to add parport and parport_pc back before the hal_parport module would load, however. In addition, I also ran a build-in-place 2.8-pre release, all with no joy.


PCW was kind enough to test a few J1900/1800 motherboards and they look OK (although I'm not sure if they were Asrock). micgres found a link to a user having a similar issue with an Asrock Q1900B-ITX (similar but not the same exact model). Unfortunately no resolution is listed. The discussion starts with user "ArturM" on page 5. Looks like he is trying to send the inputs from a spindle or servo encoder but they aren't making it from the parallel port into LinuxCNC.

www.cnc.info.pl/topics54/linuxcnc-na-j1900b-vt61463.htm

translate.google.com/translate?hl=en&sl=...00b-vt61463%2C40.htm


I'm a newbie, but it appears to be related to some combination of my hardware, HAL and/or RT and the hal_parport driver. Any help would be appreciated greatly. Thank you!

Are you probing the pins directly on the motherboard header or do you have a header -> 25pin dsub cable? (if the latter - are you sure all the pins are correctly wired through?)

sam

The mother boards that I tested were:

Asrock Q1900-ITX

Gigabyte GA-J1800N-D2H

Both work fine

Just to amplify skunkworks point.

The headers have 26 pins, a parport 25, it has caused problems before when the user has connected to the 'dead' pin because it was unclear which pin was No1.

regards

Thanks for the replies so far. I buzzed out my parallel port cable and confirmed it's a standard IEEE 1284 straight through DB25F to DB25M. I also re-confirmed that my 26-pin header to DB25F cable is correctly attached to the motherboard. I didn't buzz out the DB25M-DB25M gender changer that came with the MX3660, but I don't believe cabling is part of my issue. The ptest application shows all red inputs immediately upon startup, even with nothing attached to the motherboard parallel port header. When cabled, I can see inputs just fine with the ParallelPortTest app. In addition, my XYZ step and direction outputs are also fully functional w/ LinuxCNC.

You might want to verify that the motherboard LPT header pinout is correct for IDC flat cables

I know that motherboard COM port headers come in 2 incompatible pinouts (one for IDC and one with 1-1 pinout)
LPT headers might be the same...

Hi All, updating for Saturday...

I've been over the BIOS and pinouts/wiring several times and I'm confident that is not an issue. I've tried the stock LinuxCNC version on the Wheezy ISO, as well as a recent 2.8 pull from the git repo. I also added some machinekit repos and booted up the 3.8-1-xenomai.x86-686-pae kernel, all with no luck in the ptest.hal test application. In all cases, I can see my inputs just fine with the ParallelPortTester application. I can also drive my outputs in both ptest.hal and ParallelPortTester by hand by clicking rapidly on the correct pins (6 for my Z axis, as an example).

I'm convinced at this point it's a combination of my HW and the HAL parallel port support. Can anyone suggest some software debugging steps? Thanks.

PCW spent a significant amount of time with me today (THANKS!) and I ended up solving my problem by driving pins 10-13,15 to +5V with five 2.2K resistors. This allows me to use my 4 digital inputs on the MX3660 along with the e-stop input. It's possible that this is a software mode-setting issue, or perhaps this motherboard just doesn't have pull-up resistors. If it is software folks with Nuvoton NCT6776D Super I/O chips may want to take warning.

Thanks very much again to PCW and micges. I'd be happy to help anyone debug this further and put it to bed, but I'm moving on for now. Thanks.

I got the asrock Q1900M Pro3 and i have the same problem.
Inputs in parallel 25 pin port did not work.
I have this breakout board www.ebay.com/itm/5-axis-CNC-Breakout-Boa...-MACH3-/310684740550
At input pins have optocouplers for protection and has input for 2 supplies 5V from pc usb and 12-24V isolated from 5V that becomes 10V with an lm317 regulator. 10V and 5V are isolated with optocouplers.
10V is driving the optocouplers for inputs and the pwm of spindle, 5V driving all the rest.
How to fix it ? Where to put pullup resistors at inputs of bob or at inputs of mobo parport ?

Also jitter is big about 30000ns what to do to lower it ? Any tips for improvement ?
I will put a mesa card in future because i don't like the idea for software signals generation but for now i want to test it with parport.

As Adam3999 said the problem is that the inputs dont seem to have pullups
so if you expect a change by grounding a pin you wont see it
(and the inputs must be driven to either high or low states)