Parallel port directly to Servo Drives

Hi All,
Fairly straightforward noob question here. I am rebuilding the controls for an old Precix CNC. I have all the servo drives / encoders functioning properly and I have managed to control everything with step/dir pulses generated off a Teensy3.6 micro-controller. Now I'm trying to get everything set up with LinuxCNC. My first step is to try to get a single axis moving the way I want through the parallel port. I'm using old DG2S drives from CNCDrive (www.cncdrive.com/DG2S_16035.html).

Am I being naive to connect the Step/DIR/COM pins of the driver directly to the pins on the Parallel Port (Pin 1 - Step, Pin2-DIR, and Pin 25-GND)? Please note: The driver is optically isolated, and the data sheet claims to "buffer" the signals (whatever that means). I am getting very strange "crunchy" movement out of the motors where before it was smooth (with the Teensy). After a (very) short period, it also seems to freeze up and the parallel port stops sending out the pulses.

I have a bunch of stuff, including a Mesa PCIe board, on the way in case I need it, but I would love to know if there is something critical I am missing here. I am, in particular worried that there is something I am missing about how all the GND's connect (or don't), though I should say that there IS NOT a ground loop between the drive power (40-45VDC), and anything else. The other supplies are +5V for encoder and 12V for driver logic, and then there is the DB25 GND. Not sure where all these GND's need to go. I assumed that the COM for the Step/DIR would ground to the DB25 ground, and the 12V driver logic supply and the 5V encoder supply could be ground together.

As always, I greatly appreciate the free help and advice that this forum provides, and thank you in advance for reading/responding.

Thanks.

Are the step/dir inputs isolated so you can choose active high (what you are using now) or active low (common 5V rather than common GND) drive?

Optocouplers often need more drive than a bare parallel port can provide
especially in active high mode

I'm not sure I understand. But, I searched the data sheet (linked above) really quickly:

"Step signal active and inactive edges can be configured in software by user." (There is a USB diagnostic tool called "servo-configurator" for these drives.)

"Step and Direction source signals are fed to the DG2S drive through built in high speed 10Mbit/sec optoisolators. The step and direction inputs interface includes an analog and also a digital filter, these filters out short pulses and noise spikes. Direction signal stabile state minimum allowed valid time after step signal active edge: 1usec"

I see nothing explicitly about active low anything for Step/Dir.

As to the 2nd part of your reply. Are you saying it has to do with how much current the driver is drawing, or voltage? Should I be worried if my parallel port is outputting slightly less than 5V? I assume you are suggesting that active low will still trigger if the voltage isn't quite high enough, whereas active high won't. Please excuse my hopeless ignorance.

Active low will always drive the System better then the High signals
That is why most Stepperdriver got a 5V+ chain and run on active low pulse

most servo drives use a internal pullup

The active low approach seems to be working miracles, and it is suddenly much much much more reliable. However, if I leave the test axis window open for a few minutes and come back, it will no longer respond. The computer itself is not frozen; I can close out the window and restart Stepconf, but test Axis still won't cause motion. After several reboots, I can say it seems to go dead after about 45 seconds.

I am fairly certain the servo drive is not in fault mode because the corresponding indicator lights are a-okay.

As I mentioned before I have the 12V for driver logic grounded together with the 5V for the encoder power and the parallel port GND on pin 24. I also tried this with the parallel port ground only connected to the step/dir COM wire-- same results.

UPDATE: When running the pport tester from command line. All pins function fine, and then after a moment I get the dreaded "Unexpected realtime delay on task 0"

I've run latency-test five million times, and the worst case when I really push it is 30000us. I ran that through the spreadsheet and set my base_period to 32500. I've disabled all power management in BIOS, audio, fan-control etc, single-core, etc etc. I haven't found anything online about any of my hardware being funky (it's a Dell Optiplex 3020). There doesn't really seem to be a latency issue as far as I can tell. I have to run it for an hour with a million OpenGL windows open for it to go above 10000). I'm not sure why I'm getting this message.

Hardware:
Dell Optiplex 3020
Lexar SSD
Intel(R) HD Graphics 4600
Standard SATA AHCI Controller
PCIe to Multi-mode Parallel Port
Intel Core i5-4590 CPU @ 3.30GHz

Edited /etc/default/grub to include idle=poll and isolcpus=3(recommended for PREEMPT)

With 21 seperate instances of GLXGears running:



Directly after ptester stops working:
cncuser@debian:~$ dmesg | tail -50
[ 2.575993] [drm] Initialized
[ 2.594076] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 2.608216] parport0: PC-style at 0xe010 (0xe000), irq 16 [PCSPP,TRISTATE,EPP]
[ 2.624776] systemd-journald[218]: Received request to flush runtime journal from PID 1
[ 2.648583] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 2.648608] sr 5:0:0:0: Attached scsi generic sg1 type 5
[ 2.712258] [drm] PipeC fused off
[ 2.713171] [drm] Memory usable by graphics device = 2048M
[ 2.713172] [drm] Replacing VGA console driver
[ 2.713711] Console: switching to colour dummy device 80x25
[ 2.729178] input: PC Speaker as /devices/platform/pcspkr/input/input8
[ 2.736576] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 2.736577] [drm] Driver supports precise vblank timestamp query.
[ 2.743258] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 2.756575] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms ovfl timer
[ 2.756576] RAPL PMU: hw unit of domain pp0-core 2^-14 Joules
[ 2.756577] RAPL PMU: hw unit of domain package 2^-14 Joules
[ 2.756577] RAPL PMU: hw unit of domain dram 2^-14 Joules
[ 2.756578] RAPL PMU: hw unit of domain pp1-gpu 2^-14 Joules
[ 2.782459] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 2.782909] acpi device:60: registered as cooling_device6
[ 2.782965] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input9
[ 2.783049] snd_hda_intel 0000:00:03.0: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
[ 2.783067] [drm] Initialized i915 1.6.0 20160919 for 0000:00:02.0 on minor 0
[ 2.787752] Adding 16693244k swap on /dev/sda6. Priority:-1 extents:1 across:16693244k SSFS
[ 2.796401] lp0: using parport0 (interrupt-driven).
[ 2.797895] fbcon: inteldrmfb (fb0) is primary device
[ 2.823673] input: HDA Intel HDMI HDMI/DP,pcm=3 as /devices/pci0000:00/0000:00:03.0/sound/card0/input10
[ 2.831148] dcdbas dcdbas: Dell Systems Management Base Driver (version 5.6.0-3.2)
[ 2.873307] Console: switching to colour frame buffer device 160x64
[ 2.877099] kvm: disabled by bios
[ 2.888551] intel_rapl: Found RAPL domain package
[ 2.888552] intel_rapl: Found RAPL domain core
[ 2.888552] intel_rapl: Found RAPL domain uncore
[ 2.888553] intel_rapl: Found RAPL domain dram
[ 2.888555] intel_rapl: RAPL package 0 domain package locked by BIOS
[ 2.888558] intel_rapl: RAPL package 0 domain dram locked by BIOS
[ 2.891709] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 2.955263] dell_wmi: Detected Dell WMI interface version 1
[ 2.955304] input: Dell WMI hotkeys as /devices/virtual/input/input11
[ 3.045039] iTCO_vendor_support: vendor-support=0
[ 3.045841] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.11
[ 3.045879] iTCO_wdt: Found a Lynx Point TCO device (Version=2, TCOBASE=0x1860)
[ 3.045955] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[ 3.116171] clocksource: Switched to clocksource tsc
[ 3.386017] r8169 0000:03:00.0: firmware: direct-loading firmware rtl_nic/rtl8168g-2.fw
[ 3.458413] r8169 0000:03:00.0 eth0: link down
[ 3.458702] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 123.470340] random: crng init done
[ 123.470342] random: 7 urandom warning(s) missed due to ratelimiting

Is there any hope?

tommylight wrote:

drew_hamilton wrote:

....... After a (very) short period, it also seems to freeze up and the parallel port stops sending out the pulses..

If the PC is freezing up, there is something wrong with the wiring or grounding, so you should check that first.
If it is not, just ignore this reply.

It could also mean the base thread period is too short for the CPU. I'd try increasing the base thread period by 20% and see if that helps.

Jon

At this point I have literally everything but XSTEP/XDIR and GND unplugged.

With Base Period set to 120% (1200000) and 200% in the INI file (2,000,000), I seem to still get the error. In the parallel port tester it takes much longer than it did before for the "unexpected realtime delay on task 0" to pop up, but in the Axis Test function of StepConfig, it doesn't take much time at all (maybe 1 minute of moving the axis around) before motion stops.

I tried setting all pins to "Unused" except 1,2 and 25, but that has no effect.

I just don't see how this matches up with my latency-test results. I feel like something else is going on. How can this be so easy for me to run with an Arduino, yet so hard to run with LinuxCNC?

Does anyone see anything funky in the dmesg that I should be worried about?

[Issue Resolved (sort of]:

Just wanted to wrap this up for anyone that might have the same or similar issue. I recieved the Mesa 6i25 PCIe card and the 7i76D daughter card that goes with it. Everything seems to be working fine. I cant say for sure what was wrong with the other setup-- all the wiring is the same-- but I'm up and running and I'm probably better off in the long run because it will make it easier to add bells and whistles and I don't need software step generation.

If you're new like me, and you're reading this post in the future. Save yourself the tears and just order these two (or similar cards) like everyone told you to do in the first place.

Cheers.