Asrock Q1900B-ITX

Ok. Temps are also easy to check by installing lm-sensors package.
I'm planning to use Chieftec 120W supply. The wall block gets only slightly warm and the pcb part stays cold.

Depends on the wall-wart and mini-psu used, some mini-psus let the incoming 12vdc straight through and then the wall-wart part must be good enough for the mb & co.

Hi again

Unfortunately I counld't get more memory to test.

There is a not-so-nice thing with the parallel port.
The 8 data lines (pins 2-9) give 0/3.3V as they should. But the other outputs (pins 1, 14, 16 and 17) give only ~1.2-1.4V when set to 1 on linuxcnc.
According to the NCT6776D datasheet all these outputs are of same type, 12mA source/sink (page 9, 11,12) here

Also tried to change mode on bios but that has no effect on voltage levels.

I am driving HCPL-2630 optocouplers with 470ohm resistors which results in about 4mA drive current which should be acceptable for any parallel port. Measured on pins 2-9 voltage is 3.1V and drive current 3.3mA.

I also tried with a 2.5k pull-up on pin 1, setting 0 gives ~90mV and high ~2.2V so it's not an open drain.

Maybe the board is broken ?


And yes, my cable is correct, those outputs were not shorted to ground in any moment.

Edit: this was interesting.
Problem went away with this: disable parport in bios, boot (linux does not find parport). Reboot, set parport to manual, ECP1.7, 0x278, all irqs => works as it should.

Edit: this was interesting.
Problem went away with this: disable parport in bios, boot (linux does not find parport). Reboot, set parport to manual, ECP1.7, 0x278, all irqs => works as it should.

I like your thinking

Today I decided to test if he uspace version is suitable for paraller port usage too because of the good looking latency.
Installed using linuxcnc-stretch-uspace-amd64-r13.iso image.
Latency is quite good, ~4000 servo, ~13000 base (2x 8G samsung M471B1G73QH0-YK0 memory modules) with kernel command line "isolcpus=2,3 acpi_irq_nobalance noirqbalance"
Using irq affinity (all to cpu0) discussed elsewhere in forum the latency is a bit better but not significantly (only a few hundred after overnight test).

Latency stays at max ~5000 servo, ~15000 base when running overnight with 6 glxgears and youtube. Additional load with samba & file transfer does not make a difference.

But when starting linuxcnc I always get "Unexpected real time delay on task 0".

uname -a:
Linux sorvi 4.9.0-8-rt-amd64 #1 SMP PREEMPT RT Debian 4.9.110-3+deb9u6 (2018-10-08) x86_64 GNU/Linux

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.9.0-8-rt-amd64 root=UUID=a07de53a-6564-44d7-b7c6-86c7ea742140 ro quiet isolcpus=2,3 acpi_irq_nobalance noirqbalance

Linuxcnc output on terminal:
Unexpected realtime delay on task 0
This Message will only display once per session.
Run the Latency Test and resolve before continuing.
Unexpected realtime delay on task 0
This Message will only display once per session.
Run the Latency Test and resolve before continuing.
Shutting down and cleaning up LinuxCNC...
task: 2050 cycles, min=0.000022, max=0.011068, avg=0.009994, 0 latency excursions (> 10x expected cycle time of 0.010000s)
Note: Using POSIX realtime

Linuxcnc 2.7.14 seems not to print anything to view with dmesg. No _print.txt or _debug.txt on home directory.

Any ideas why unexpected delay happens on startup with those latency numbers ?
Or something else that can cause unexpected delay ?

Maybe I should still stay with the old rtai version if this cannot be solved... odd because of the latency should not be an issue by looking at the numbers.

The uspace version of linuxcnc does not print to the kernel log.
To view the linuxcnc messages, start linuxcnc from the command line (just type "linuxcnc") and you should see the same output as RTAI versions print to dmesg.

It would be interesting to run a test where a step generator output is fed to an arduino or similar, with the time between steps logged by the arduino and process into 10 second bins and then sent back through USB for analysis.

Or simply run an actual stepper motor and see if the noise sounds very regular.

It is possible that this realtime delay message is spurious, or is a one-time thing at realtime startup.

Am I right that we are talking about results tested on rtai kernel? On rt-preempt kernel I have huge worse results comparing to the rtai. Main problem with rtai debian wheezy is unsupported graphics on this motherboard. The resolution and rendering is bad enough.