Separating DRO from actual controller

[Saur0o0n]

This is more like question/idea to consider.

After some successful testing (still on Uno yet) I try now to arrange my controlling stuff and power supply distribution to find proper casing for it.
You can see the picture just as reference. Anyway this is going to be big (there is no actual 48V - 30A power supply on picture), so I would like to have it somewhere hidden from all the dust/scraps. But here comes the problem with DRO - it's pointless to locate it in hidden place.

I started to think how I could separate LCD, keypad, wheel - to make it movable and somewhere more accessible then the rest of the stuff. The best solution would be to have a small box with just those parts and long wire. But here comes another the problem,
I could have a long wire for LCD, wheel and keypad and Arduino inside the "big box" with all the other components, or send all the controls to spindle and motors over the long wire and have Arduino in small box with LCD.
I don't like the second idea, and frankly the first one is also awkward because of 24 wires required and I don't know how it will react for all interferences.

I guess best solution would be to have 2 Arduinos - one for CNC control, another just for DRO and create some communication channel between them. I know this would change the project quite heavily - but I guess I'm not going be the only one that will face this problem.

What do you think?

[bdurbrow]

In theory, if the wires are all run in grounded metal conduit, interference shouldn't be a major problem (reflections & termination might be an issue, however).

Of course, in theory, there is no difference between theory and practice, but in practice... well, you get the idea.

For my larger machines, I'm using GeckoDrive G203V drivers for the axis motors. The GeckoDrives will be mounted in a separate electrical box, with between 2 and 6 feet of cable between them (depending on which machine one is looking at - one is a Sieg X3 benchtop mill conversion, the other is a Shizouka AN-S CNC knee mill from the 1970s that's about 7 feet tall).

For this purpose, I designed two styles of breakout board (they use a pinout very similar to what a RAMPS uses; so modifying my grbl version to support it was a minimal effort). These were the PCBs that I mentioned had arrived, in the other issue on hooking up the Chinese spindle with 0-10v PWM drive.

One of them has places on the board for 5mm pitch screw terminals; and the other has a 26 pin header with a pinout intended to match the pinout of a GeckoDrive G540... which is what I'm going to be using to remotely locate the GeckoDrives from the Arduino.

The signal flow goes something like this:

Arduino --> Breakout Board --> 26 pin header to Parallel Port adapter (1) --> Shielded DB25 cable --> DB25 Breakout Board (2) --> G203V drives.

(1) : This is a standard PC cable for connecting the parallel port header on the motherboard to a DB25 socket on the back of the case. I used it because it's convenient and readily available.
(2) : This is a standard breakout board sourced from eBay. I'm using it because I'm using G203V drives, not an actual G540. People who have a G540 wouldn't need this; the shielded parallel port cable would plug directly into the G540.

The G203V drives have optoisolated inputs; and thus the signals are current-mode; not voltage-mode. Among other things, this helps with reflections and noise. It looks from that photo that your drives are also optoisolated? If so, that will help significantly.

I guess best solution would be to have 2 Arduinos

The problem with having two Arduino's connected like that is the same problem with having a PC streaming over the serial port - synchronization and latency. It could be the placebo effect, but I can feel the difference in responsiveness between having the jog encoder wheel's ISR turned on, and having it revert to polling. My experience with trying to do jogging over the serial port was even worse... for that matter, I'm also not terribly fond of these new 'all-graphics' front ends on dedicated CNC controls (Hass, etc), compared to the old character-based displays - they have noticeable update lag that the old ones just didn't have.

This is not necessarily an insurmountable issue; however it is a non-trivial one. One possibility might be to leverage the ethernet physical layer; but run a protocol specifically designed for this (one does not need address fields in the frames, and there's no need for collision handling; for example). In any case, substantial custom hardware would be needed.

[Saur0o0n]

Yes, those X/Y controllers are optoisolated, my Z is still on stepstick (since it still on nema17 - X/Y are on Nema23 3A) - but I guess I'll have to change it now, just to make it cleaner solution. I'm not sure how is the spindle driver (pink one) - but this would be only PWM for RPM control.
But the idea of DB25 is kind of nice - this could be used for DRO signalling (I still prefer - guts feeling - to have controller closer to drivers then to DRO).
There are even ready to use breakout boards: https://www.aliexpress.com/item/32695664305.html

Hmmm.. but I've ditch long time ago my last parallel cables - because never though I'll use it ever again. :)

Thx for concise answer!

[bdurbrow]

That's actually the exact DB25 breakout board I'm going to be using... except I got it off of eBay, not aliexpress.

As far as signal integrity goes... well... the Mach 3 folks seem to have been getting away with just a regular DB25 parallel printer cable for quite a while... and, well, back before USB that's what printers used... and I know I've had some awfully long SCSI chains set up way back when...

[Saur0o0n]

You can get them even cheaper - I've ordered those - under 3$.
Mach3 Db25 are optoisolated and they are from era where there where no other solution possible - computer had to maintain every step of every motor. Frankly, when I was deciding on my first cnc machine this made me uncomfortable :) But that's true - I've worked on meters long SCSI cables and used parallel cable to create first "network" on two Amigas. It worked - but I would call it convenient this days.

[bdurbrow]

Oddly enough, I've had better luck actually receiving packages from eBay than on Aliexpress... I have no idea why, they are both coming from the same place (China). Perhaps it's just my bad luck... ???

---

The output from Mach was just whatever parallel port happened to be in the PC... usually, whatever the super-io chipset provided; although occasionally it was a dedicated PCI I/O card. Sometimes a PCI card was required because the motherboard chipset wasn't putting out a full 5 volts (usually when this happened, it was pulling up only to 3.3 volts) but the stepper drivers wouldn't trigger unless a higher threshold voltage was reached.

Depending on the machine - or more to the point; the stepper drivers and/or breakout board that the PC was interfaced with - it may or may not have been optoisolated. Better setups, of course, were.

What made me uncomfortable about the whole thing was the deep dark magic that Art had to do to make Mach work in the first place - living under the Windows NT kernel is not the greatest place to be when you are trying to eliminate jitter from a software-generated pulse stream. Intel's various system management firmware hasn't helped matters either - it can take over control of the CPU from the kernel, and I've heard of cases where that can stretch into the hundreds of milliseconds, rendering some PCs simply unsuitable for running Mach with a parallel port output.

[Saur0o0n]

I've created printable DRO case. If anyone wish to use it - go ahead :)
It's finished now.

https://www.thingiverse.com/thing:3874221

[Saur0o0n]

I've updated project with additional space for DE15 socket and place for 3xtac switch and 3x5k potentiometers.
https://www.thingiverse.com/thing:3874221

[bdurbrow]

Nice! One of these days when I have some time I'll have to send it to my 3D printer... (going to be stuck running a tractor all weekend, and I don't like leaving the printer running unattended).

[Saur0o0n]

It's seems like this idea will fail after all. I've done everything what I wanted so far with my CNC router, and on the very end I wanted to add DRO. Sadly it looks like signals from Arduino Mega to LCD/jog are too much distorted to be useful.
It looks like guilty part is interference from motor drivers (disconnecting motors helps) - but since they are already in shielded cables (even inside the box), there is not much I can do. Shielding brakeout board for DB25 helps a bit - but there is still a lot of errors on screen.
I've tried to do more shielding inside the box - but since cables are from different parts of the board, they can't be protected thoroughly.
So it seems like having Arduino inside the DRO and sending signal to separated drivers is the way to go. Perhaps splitting motor/spindle drivers in to separated metal box would also help - but I'm not sure at this point if it's worth to try.

[bdurbrow]

Hmm... I'm also thinking a differential driver setup might be useful. After I get the other PCBs tested and and gerbers posted; I'll see if I can cook something up. Shouldn't be hard.

The other thing to look at is that I'm driving the LCD somewhat faster than the original (1980s?) HD44780 data-sheet says is OK... mostly because a) it helps with system responsiveness (there's a busy-wait loop involved; the ISR can take over during it, but the main loop is stalled); and b) modern LCDs I tested here seemed to work OK (newer chip; faster performance, I guess). See LCD_SEND_DELAY in cpu_map.h to adjust it.