Re: [Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[Chris Albertson]

You are right, pushing high speed signal over long distances is not an
easy task.   It is no coincidence that the faster electronics are also
physically smaller.  With a given technology the way to go faster is
to get smaller.  This applies to CPU chips and also cables.

On Sat, Dec 24, 2016 at 1:44 PM, Bertho Stultiens  wrote:
>
> 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.


You have to be a little careful.   Most round cables you buy today say
"IEEE 1284" and these are the ones that allow data to go up to 30 feet
at up to about 2MHz.   But this assume good driver/buffers and old
style 74xx logic chips.The really old cables or those you make
yourself are good for maybe 1/2 these specs.   But IEEE 1284 is so old
almost anything sold as a "parallel printer cable" will be made to
this spec.But not so for old "junk drawer" parts.  So there is
"old school" and "really old school" you have to check what you have

I would start by testing with signals below the KHz range.  Maybe 100
steps per second on one axis.

-- 

Chris Albertson
Redondo Beach, California

--
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

Re: [Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[Gene Heskett]

On Saturday 24 December 2016 16:44:53 Bertho Stultiens wrote:

> 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.

Yes we are. I just this instant got past the roadblock with an r-pi using 
the SPI interface. The cable is a 26 line ribbon, src terminated, and 
running at 30 megahertz over about a 8" total cable length.  The src 
terms are about an inch away from the gpio pins.

Needless to say, my ears hurt, the grin, after all the headache from 
beating my head on the wall, is that wide.

> > 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.


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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.

Re: [Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[Bertho Stultiens]

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

Re: [Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[Chris Albertson]

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.

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

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

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.

On Sat, Dec 24, 2016 at 4:20 AM, Gene Heskett  wrote:

> Greetings folks;
>
> This is a heck of a thing to throw out on Christmas Eve.
>
> I am about burned out on trying to make the raspi 3b work.
>
> I saw it work once, for about 2 days, then an update blew it up by
> replacing the rt kernel, and it has not worked since. In the sd cards
> I've made since, probably 8 or more, following the recipe given, the
> halrun;halc md loadrt hostmot2;loadrt hm2_rpspi test procedure works
> perfectly.  But linuxcnc refuses to load that hm2_rpspi driver.
>
> Mr. Martinjack built me an image and sent me the link to it. No gui, so
> testing would have to be done over an ssh -Y login.  He, I believe went
> to quite some effort to do that, and I assume that it worked on his
> raspi-3b. But when I wrote it to a zeroed 32Gb card, expanded the
> filesystem on the first boot, then configured the networking in static
> mode, making it immutable as I went so whatever raspian uses in place of
> network-mangler can't tear it down on the next boot, the result can't do
> the halrun test.
> ---
> pi@raspberrypi:~ $ halrun
> halcmd: loadrt hostmot2
> Note: Using POSIX realtime
> hm2: loading Mesa HostMot2 driver version 0.15
> halcmd: loadrt hm2_rpspi
> Unknown board: HOST
> hm2_rpspi: rtapi_app_main: Operation not permitted (-1)
> :2: waitpid failed /usr/bin/rtapi_app hm2_rpspi
> :2: /usr/bin/rtapi_app exited without becoming ready
> :2: insmod for hm2_rpspi failed, returned -1
> -
> which is the same failure I get when trying to start linuxcnc on one of
> my builds.
>
> And this is the 2nd pi-3b I've put in.
>
> Does my use of a 32GB card have anything to do with this?
> Does my use of the full jessie install instead of the jessie-lite have
> anything to do with this? I can try that once.
>
> If that fails, I'll quit beating my head with a hammer and reset this
> 7i90 to an epp interface and go back to an x86 computer to drive it, but
> that brings up the next $64K question.  The big old Dell I have to drive
> it with isn't swarf proof by any means, and it will take at least 6 or
> even 8 feet of ribbon cable to get it far enough away from the swarf to
> be safe from flying chips.  Can I use a ribbon cable that long with good
> results?  The man page says it could be a problem but doesn't say how
> long is too long.  And I've no clue if the parport on this old Dell can
> be made epp-1.9 compliant.  TBD I guess.
>
> Thanks everybody. And have a Merry Christmas.
>
> Cheers, Gene Heskett
> --
> "There are four boxes to be used in defense of liberty:
>  soap, ballot, jury, and ammo. Please use in that order."
> -Ed Howdershelt (Author)
> Genes Web page 
>
> 
> --
> 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
>



-- 

Chris Albertson
Redondo Beach, California
--
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

Re: [Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[Gene Heskett]

On Saturday 24 December 2016 12:40:43 Bertho Stultiens wrote:

> On 12/24/2016 01:20 PM, Gene Heskett wrote:
> > If that fails, I'll quit beating my head with a hammer and reset
> > this 7i90 to an epp interface and go back to an x86 computer to
> > drive it, but that brings up the next $64K question.  The big old
> > Dell I have to drive it with isn't swarf proof by any means, and it
> > will take at least 6 or even 8 feet of ribbon cable to get it far
> > enough away from the swarf to be safe from flying chips.  Can I use
> > a ribbon cable that long with good results?  The man page says it
> > could be a problem but doesn't say how long is too long.  And I've
> > no clue if the parport on this old Dell can be made epp-1.9
> > compliant.  TBD I guess.
>
> The achievable length of the cable is usually determined by the cable
> loss and the impedance matching of the cable.
>
> In principle, you can roll out 25m of parallel port cable if you
> ensure that firstly, the drive power is sufficient to overcome the
> capacitive load of the cable and secondly, that the cable-impedance is
> matched either with driver-side series resistors or symmetrical
> termination on each side. (*)
>
> The drive power of most "old-style" parallel ports is enough to drive
> 10m of cable. However, the reflections are significant and interfere
> with higher frequency signaling (step-signals are fast enough to
> suffer).
>
> The cable impedance is usually around 100 Ohms (maybe 120 for some).
> Thus, inserting a 100..120 Ohm series-resistor on each output driver,
> just before entering the cable (ideally at the driver output pins of
> the driver chip), should be a nice enough match for most cases and
> uses. Just be sure that you identify the correct side of the cable
> where to insert the resistor. It must be done on the drive-side to be
> effective. If you have bidirectional communication on a wire, then it
> becomes a bit more difficult. But that usually does not happen on most
> EPP setups and the inputs and outputs are perfectly defined and
> constant.
>
> (*) I am ignoring common-mode and ground problems here, just as
> shielding. If your environment is balanced enough and not EMI
> infested, then you should not see too many problems.

Thats encouraging Bertho. If I can beat the parport into epp,v1.9 mode, 
we'll try 10 feet.  EMI could be a problem as the power goes up to the 
VFD, and the VFD drive comes back, thru the same length non-shielded 
plastic bx. That isn't going to be common with the ribbon cable, nor 
with the isolated 4 wire from the spinx1 to the vfd.

I won't know for sure till its been tried. :) or :(  But this is 
Christmas Eve. So almost nothing will be done till Monday.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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

Re: [Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[Bertho Stultiens]

On 12/24/2016 01:20 PM, Gene Heskett wrote:
> If that fails, I'll quit beating my head with a hammer and reset this 
> 7i90 to an epp interface and go back to an x86 computer to drive it, but 
> that brings up the next $64K question.  The big old Dell I have to drive 
> it with isn't swarf proof by any means, and it will take at least 6 or 
> even 8 feet of ribbon cable to get it far enough away from the swarf to 
> be safe from flying chips.  Can I use a ribbon cable that long with good 
> results?  The man page says it could be a problem but doesn't say how 
> long is too long.  And I've no clue if the parport on this old Dell can 
> be made epp-1.9 compliant.  TBD I guess. 

The achievable length of the cable is usually determined by the cable
loss and the impedance matching of the cable.

In principle, you can roll out 25m of parallel port cable if you ensure
that firstly, the drive power is sufficient to overcome the capacitive
load of the cable and secondly, that the cable-impedance is matched
either with driver-side series resistors or symmetrical termination on
each side. (*)

The drive power of most "old-style" parallel ports is enough to drive
10m of cable. However, the reflections are significant and interfere
with higher frequency signaling (step-signals are fast enough to suffer).

The cable impedance is usually around 100 Ohms (maybe 120 for some).
Thus, inserting a 100..120 Ohm series-resistor on each output driver,
just before entering the cable (ideally at the driver output pins of the
driver chip), should be a nice enough match for most cases and uses.
Just be sure that you identify the correct side of the cable where to
insert the resistor. It must be done on the drive-side to be effective.
If you have bidirectional communication on a wire, then it becomes a bit
more difficult. But that usually does not happen on most EPP setups and
the inputs and outputs are perfectly defined and constant.

(*) I am ignoring common-mode and ground problems here, just as
shielding. If your environment is balanced enough and not EMI infested,
then you should not see too many problems.

-- 
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

Re: [Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[John Thornton]

Merry Christmas Gene.

JT


On 12/24/2016 9:58 AM, Gene Heskett wrote:
> On Saturday 24 December 2016 09:41:48 John Thornton wrote:
>
>> Hi Gene,
>>
>> You could use this:
>>
>> http://mesaus.com/index.php?route=product/product=71_id=5
>> 9
>>
>> with this:
>>
>> http://mesaus.com/index.php?route=product/product=71_id=7
>> 0
>>
>> To get 7' between the 7i90 and the PC.
>>
>> JT
> The 5i25 doesn't have a bit file that can drive the 7i90 in epp mode
> according to Peter. So this cable would be from the parport on the dell,
> to the 7i90. I'll find out as I have a box of cable and some connectors.
>
> Thanks John. Have a Merry Christmas.
>
> Cheers, Gene Heskett


--
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

Re: [Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[Gene Heskett]

On Saturday 24 December 2016 09:41:48 John Thornton wrote:

> Hi Gene,
>
> You could use this:
>
> http://mesaus.com/index.php?route=product/product=71_id=5
>9
>
> with this:
>
> http://mesaus.com/index.php?route=product/product=71_id=7
>0
>
> To get 7' between the 7i90 and the PC.
>
> JT

The 5i25 doesn't have a bit file that can drive the 7i90 in epp mode 
according to Peter. So this cable would be from the parport on the dell, 
to the 7i90. I'll find out as I have a box of cable and some connectors.

Thanks John. Have a Merry Christmas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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

Re: [Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[John Thornton]

Hi Gene,

You could use this:

http://mesaus.com/index.php?route=product/product=71_id=59

with this:

http://mesaus.com/index.php?route=product/product=71_id=70

To get 7' between the 7i90 and the PC.

JT


On 12/24/2016 6:20 AM, Gene Heskett wrote:
> Greetings folks;
>
> This is a heck of a thing to throw out on Christmas Eve.
>
> I am about burned out on trying to make the raspi 3b work.
>
> I saw it work once, for about 2 days, then an update blew it up by
> replacing the rt kernel, and it has not worked since. In the sd cards
> I've made since, probably 8 or more, following the recipe given, the
> halrun;halc md loadrt hostmot2;loadrt hm2_rpspi test procedure works
> perfectly.  But linuxcnc refuses to load that hm2_rpspi driver.
>
> Mr. Martinjack built me an image and sent me the link to it. No gui, so
> testing would have to be done over an ssh -Y login.  He, I believe went
> to quite some effort to do that, and I assume that it worked on his
> raspi-3b. But when I wrote it to a zeroed 32Gb card, expanded the
> filesystem on the first boot, then configured the networking in static
> mode, making it immutable as I went so whatever raspian uses in place of
> network-mangler can't tear it down on the next boot, the result can't do
> the halrun test.
> ---
> pi@raspberrypi:~ $ halrun
> halcmd: loadrt hostmot2
> Note: Using POSIX realtime
> hm2: loading Mesa HostMot2 driver version 0.15
> halcmd: loadrt hm2_rpspi
> Unknown board: HOST
> hm2_rpspi: rtapi_app_main: Operation not permitted (-1)
> :2: waitpid failed /usr/bin/rtapi_app hm2_rpspi
> :2: /usr/bin/rtapi_app exited without becoming ready
> :2: insmod for hm2_rpspi failed, returned -1
> -
> which is the same failure I get when trying to start linuxcnc on one of
> my builds.
>
> And this is the 2nd pi-3b I've put in.
>
> Does my use of a 32GB card have anything to do with this?
> Does my use of the full jessie install instead of the jessie-lite have
> anything to do with this? I can try that once.
>
> If that fails, I'll quit beating my head with a hammer and reset this
> 7i90 to an epp interface and go back to an x86 computer to drive it, but
> that brings up the next $64K question.  The big old Dell I have to drive
> it with isn't swarf proof by any means, and it will take at least 6 or
> even 8 feet of ribbon cable to get it far enough away from the swarf to
> be safe from flying chips.  Can I use a ribbon cable that long with good
> results?  The man page says it could be a problem but doesn't say how
> long is too long.  And I've no clue if the parport on this old Dell can
> be made epp-1.9 compliant.  TBD I guess.
>
> Thanks everybody. And have a Merry Christmas.
>
> Cheers, Gene Heskett


--
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

[Emc-users] Allowable length of db25 interconnect cabling to talk to an epp version of a 7i90?

[Gene Heskett]

Greetings folks;

This is a heck of a thing to throw out on Christmas Eve.

I am about burned out on trying to make the raspi 3b work.

I saw it work once, for about 2 days, then an update blew it up by 
replacing the rt kernel, and it has not worked since. In the sd cards 
I've made since, probably 8 or more, following the recipe given, the 
halrun;halc md loadrt hostmot2;loadrt hm2_rpspi test procedure works 
perfectly.  But linuxcnc refuses to load that hm2_rpspi driver.

Mr. Martinjack built me an image and sent me the link to it. No gui, so 
testing would have to be done over an ssh -Y login.  He, I believe went 
to quite some effort to do that, and I assume that it worked on his 
raspi-3b. But when I wrote it to a zeroed 32Gb card, expanded the 
filesystem on the first boot, then configured the networking in static 
mode, making it immutable as I went so whatever raspian uses in place of 
network-mangler can't tear it down on the next boot, the result can't do 
the halrun test.
---
pi@raspberrypi:~ $ halrun
halcmd: loadrt hostmot2
Note: Using POSIX realtime
hm2: loading Mesa HostMot2 driver version 0.15
halcmd: loadrt hm2_rpspi
Unknown board: HOST
hm2_rpspi: rtapi_app_main: Operation not permitted (-1)
:2: waitpid failed /usr/bin/rtapi_app hm2_rpspi
:2: /usr/bin/rtapi_app exited without becoming ready
:2: insmod for hm2_rpspi failed, returned -1
-
which is the same failure I get when trying to start linuxcnc on one of 
my builds.

And this is the 2nd pi-3b I've put in.

Does my use of a 32GB card have anything to do with this?
Does my use of the full jessie install instead of the jessie-lite have 
anything to do with this? I can try that once.

If that fails, I'll quit beating my head with a hammer and reset this 
7i90 to an epp interface and go back to an x86 computer to drive it, but 
that brings up the next $64K question.  The big old Dell I have to drive 
it with isn't swarf proof by any means, and it will take at least 6 or 
even 8 feet of ribbon cable to get it far enough away from the swarf to 
be safe from flying chips.  Can I use a ribbon cable that long with good 
results?  The man page says it could be a problem but doesn't say how 
long is too long.  And I've no clue if the parport on this old Dell can 
be made epp-1.9 compliant.  TBD I guess. 

Thanks everybody. And have a Merry Christmas.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

--
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

Re: [Emc-users] EDM machining --> g-codes

[Nicklas Karlsson]

I started to write down whatever g-codes I can find in different dialects in 
table form.
  1. Linuxcnc, will also look for the ones you supplied.
  2. Sodick wire EDM.
  3. Charmilles sinker EDM.

Yesterday I figured out three dimensions where required so I started to enter 
in a database but today I just got up and can't figure out why two dimensions 
is not enough. A database is good anyway because data could be searched in 
different directions and presented in different forms. Most notable list 
g-codes and descriptions for all dialects for a single code.

I need to read about them anyway to learn and tables are useful to figure out 
which codes are missing and the difference between dialects. Then done it 
should be possible to place the database somewhere easily accesible from 
internet although descriptions for proprietary g-codes might cause copyright 
issues?


On Tue, 20 Dec 2016 23:23:59 +0700
TJoseph Powderly  wrote:

> Nicklas hello
> 
> 2 basic motion types are useful ( at least 2 )
> 
> 1 is jumping, a way to remove debris,
>   the debris generated in erosion needs to be removed,
> it lowers the conduction of the environment and disturbs a voltage drop 
> based control
>   flushing thru the tool is very good but it is difficult to put small 
> flushing holes thru the tool
>   these holes need to be so small that the overcut is slightly larger 
> than the radius
>   when such a small hole is used, there is no 'pin' left in the hole
>   a pin is easily thermally deformed and shorts the tools and disturbs 
> the control
>   a large pin is strong but needs to be removed mechanically afterwards 
> ( extra machining )
> 
>   so, without these holes,the motion of jumping is used.
>   no holes are made in the tool
>   the method is to cut for a while, then retract some distance and 
> return to the cut
>   this action 'pumps' clean fluid in and dirty fluid out
>   it is very effective and the user does not need tiny deep holes thru 
> the tool
>   (I've drill many feet of .012" holes thru graphite electrodes)
>   really high speed jumping will even remove carbon deposits on the 
> tools ( these deposits change the conduction too )
>   ( this carbon is not from the tool but from the electrical splitting 
> of the oil into hydrogen and carbon )
> https://www.youtube.com/watch?v=YNSh_OL035E
>   jumping is a great aid in cutting and even in arc prevention
> 
> 2 is orbiting
>   orbiting is a motion related to cutter compensation
>   the tool size can be exagerrated by motion, and the exaggeration is 
> programmable
> 
>   the tool is smaller than the desired form by an amount that is suited 
> to the roughing power settings
>   after roughing, the same tool can be used to finish despite it's 
> energy envelope is smaller
>   the smaller energy envelope would not 'reach' the work surface UNLESS 
> the tool is moved off center
>   the tool is moved to make it describe a larger tools volume.
> 
>   orbiting can be 2 or 3D in motion and 2 or 3D in undersize.
> http://www.edm.kd-solution.com/en_edm11.html
>   the big reason to orbit is to reduce the cost of making the electrodes
>   in most cuts you need multiple electrodes to make a single form
>   because there is wear on the tool when it is used
>   and
>   each tool has to be replaced onto the tool holder in _exactly_ the 
> same position, orientation, and shape
>   in old non-orbited sink edm different sized tools of the _same_ shape 
> were made and this was very expensive and time consuming
>   these tools were the rougher pre-finisher and finishing electrodes
>   with orbiting AND good tooling, only a single form has  to be produced 
> (say 3 to 5 times for high precision cavity )
> 
>   so you can make a 1" cube cavty with a .990 cube rougher and .996 
> prefinisher and .998" finisher
>   OR
>   make 3 pcs .990" cube   see its just easier to maintain precision
>   also
>   orbiting lets you adjust the final size ( you can make the tool too 
> small and still egt the right final form and precision
> 
>   the tool MUST be made with the orbit used in mind
>   the cnc edm will 'unwrap' the undersized that is 'warpped' onto the 
> electrode
> 
>   there are limitationa and tradeoffs to be considered ( generated 
> corner radii, cutting times, and more )
> 
> so jumping ( esp high speed jumping ) is really a flushing technique
> and
> orbiting is a way to make precision cavities with better control over 
> production and cost
> 
> 
> in general, edm is only used of neccesary and modern high speed mills 
> have reduced the need for most sink edm work
> but the are forms that the mills can NOT do
> sharp inside blind corners
> and
> thin deep ribs
> 
> in these operations sink edm has a strong position, and needs good 
> strategies to remove stock efficiently
> orbiting and jumping are basic strategies that are proven to make money 
> for tool makers
> 
> theres a load to this
> I have written edm orbting routines on Fanuc System 8 thru