On 12/24/2016 09:59 PM, Chris Albertson wrote:
> Read the little write up at the Mesa site about cable length.   They
> claim ribbon cable is the worst and to only use it for very short
> runs, 2 or 3 feet at most.     They suggest using "real" parallel
> cables made with twisted pairs and shielding for longer runs.  Using
> one of their fancy IEEE cables you can go up to 25 or 30 feet, half
> that with a normal round cable and half that again with ribbon
> cable.

You are right, ribbon cables are not very good at carrying signals over
long cables. They will pick up too much noise if not shielded and suffer
often from significant cross-talk if too long.

The "standard" old-school printer cables (the round ones) are often
shielded and twisted pair, which are actually quite good.


> For over 30 feet use some kind of differential signaling or fiber.

Differential signaling or fiber is of course better, but very much more
expensive. You will also need to convert the signals on each end.


> There is nothing inherently bad about ribbon cable.  It is more about how
> it is driven.  It works well as a 50 ohm transition line if you terminate
> it at each end.  The old SCSI disk drives did that.    But there is an
> upper limit on how fast you can push data down a parallel cable. This is
> why all the really fast computer interfaces are now serial

The impedance of cables is specific for each cable. You can often get
them with quite different specifications (but look the same). This is
where is gets a bit difficult. Most cabling for fast computer
electronics is 100..120 Ohms. The lower 50 Ohm cabling is too power
hungry(*) for digital logic (mainly in use in HF radio systems).
Symmetrical termination is only beneficial if you need to guarantee no
reflections in the cable, but that is not a requirement if you have a
signal only going in one direction.

Digital output buffers are generally made with low output impedance
(0.01...10 Ohms), where you make your adjustments using series resistors
at the signal's originator (the driver).

I agree that for fast comms you go to serial because it reduces cabling
complexities. However, I have a feeling that we are not talking about
signals surpassing 1..10MHz.


> Your problem might be because you are doing to much at once.  Can you get a
> one axis stepper motor to run slowly using GPIO and no FPGA card?  Does
> that work reliably through multiple upgrades and config changes or is it
> fragile?  Or even before that, can you install and update Linux and compile
> kernels and instal new drivers and run a web browsers and email and do
> upgrades and such reliably before using  RPi3 as a machine controller.

You are right that not too much must be tested at the same time. But, it
reminds me of a caution I did not mention. The cable must be driven by
actual /drivers/. FPGA outputs or the RPi GPIO pins are not suitable as
cable drivers. You need to use something that can pack a punch, current
wise, to get the signal energy into the cable and to re-absorb it when
reflected.

If you use FPGA outputs or a RPi GPIO directly, then you can expect
problems with cabling from about 0.2m onwards. Cable capacitance will
start to influence the signals and reflections are so fast that you may
overload the output pin, which might even result in silicon latch-up
problems (and subsequent crash).

Interfacing from RPi or FPGA should preferably be done using buffers.
The electronic inputs you are controlling are often not or marginally
compatible with the digital output of the computer board.

Fwiw, an old style printer port uses a 74xx245 (74xx244), where xx is LS
(very old PCs) or HCT ("newer" versions). These are real bus drivers,
which can handle the load (most of the time). The (V)LSI printer-port
chips in modern computers, just before the printer port was abandoned,
may not have a very good output drivers.



(*) This relates to the maximum power transfer theorem.

-- 
Greetings Bertho

(disclaimers are disclaimed)

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to