subject:"\[Emc\-users\] Ethernet I\/O"

Rafael Skodlar wrote:
 
 This brings up another option, build an open source EMC controller 
 PCI[e] card with slow, medium and high speed ports that could be used to 
 control buses. Speeds would need to be determined based on what is 
 required for machine world. If build with an FPGA, it would be very 
 flexible and handle a lot of logic and speed and could be programmed for 
 different needs: use with lathe, 3D routers and torch machines, or even 
 run real time functions.
This may be what Paul Corner has been ranting about for some 
time.  Port EMC(your flavor here) to one of the ARM all-in-one 
CPUs, and keep the GUI on a PC.  There are a bunch of details, 
the biggest being how to access the G-code and configuration 
files.  It would probably require more memory than they 
currently fit into such chips as the AT91SAM7X series, I think 
256 K it the max.  There apparently is a substantial speed 
penalty for external memory.  There would need to be some 
process on the PC supporting file serving to the ARM, but I 
suppose NFS would work.  Without all the Linux OS overhead and 
virtual PC nightmares of the current PC architecture, the 70+ 
MIPS of the ARM processors might be sufficient.

Once the file serving question is handled, the only serious 
remaining effort (I think) would be porting rtapi to one of the 
competing ARM RTOS options.

A very interesting idea, but it could be fairly time consuming 
to deal with all the intricacies of such a big porting effort.
It would sure make a NEAT package, and the board could be quite 
cheap.  These ARM microcontrollers are in the $7 - 14 range, 
they need an additional $12 or so of parts to implement 
Ethernet, and maybe under $10 for extra memory.  I would think 
that pat could be done for under $100.  Add an FPGA to do step 
generation or PWM drive and a bunch of I/O connections, and you
are up to maybe $200 for a commercial product.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Jarl Stefansson wrote:
 I would like to point out that ARM processors aren't the only way to go
 embedded, there are very decent x86 embedded systems available with AMD
 (Geode LX/NX) and VIA (CN/CX/C7/Eden) CPUs.
 
 System based on these can be sourced for less than $100 in bulk and as
 an added benefit none of the code needs to be ported.
 
Unless you are going to put a hard drive on there, you still 
have to problem of where the G-code files come from.
 Perhaps it's time to experiment with building a custom distro to run
 EMC2 or a subset of it on embedded systems booting from flash NAND/NOR.
 
I guess there are special file systems that reduce unneccesary 
writes to the flash memory.  or, you could put all the writable 
files on the system with the GUI.  Do these systems still have 
parallel ports?  I'm guessing these systems still have VGA 
ports, too, so you don't really need a separate system for the GUI.
 Instead of porting the code our time might be better spent optimising
 for x86 which would benefit all users.
 
 My main question is how hard would it be to run EMC in a distributed
 way so that the motion controller could run remotely from the pulse
 generator?
Hmmm, well the MPG could still be connected to the system 
running the RT section of EMC, but I'm not sure that's what you 
are asking here.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Rufi wrote:
 hello guys,
  
 I like to point you to our dspMC motion controller 
 www.vitalsystem.com/dspMC http://www.vitalsystem.com/dspMC. 
  
 the board has a blackfin DSP from Analog Devices.  the Blackfin dsp is 
 supported by Gnu/Gcc comipler and a linux port is available at 
 http://blackfin.uclinux.org.
Only $895

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-30 Thread Stephen Wille Padnos

Jarl Stefansson wrote:

I would like to point out that ARM processors aren't the only way to go
embedded, there are very decent x86 embedded systems available with AMD
(Geode LX/NX) and VIA (CN/CX/C7/Eden) CPUs.
  

If you're thinking of the small-footprint PC-like systems, you probably 
need to think again :)  The systems I've seen (and I've looked at a lot 
of them) are all meant for throughput, not latency.  They also have no 
non-PC I/O.  By that I mean that they're usually missing even the 
parallel port (though some have an internal header for it).
We're talking about the controller that actually generates step/dir or 
PWM signals, and the embedded PCs don't have the connections or the 
realtime response to do that.  They're pretty fast little processors, 
and if you want to make a little streaming video box they're great, but 
for the level of realtime performance this project would need, I don't 
think they can do the job.

Of course I'd love to be proven wrong, so if you know of a little 
embedded PC that actually has RT latencies 5-10 usec, please tell us 
about it :)

System based on these can be sourced for less than $100 in bulk and as
an added benefit none of the code needs to be ported.

Perhaps it's time to experiment with building a custom distro to run
EMC2 or a subset of it on embedded systems booting from flash NAND/NOR.
  

This would be excellent.  I have a small system that uses RTAI/HAL, and 
runs from an SSD hard drive.  I managed to get the latencies near 1 
microsecond most of the time, with outliers around 2 us.  This was done 
by using ext2 on the disk, and preventing almost everything from 
loading.  Additionally, since the PC has a core 2 duo in it, I create a 
CPU-hog process, which reduces latency from around 5-6 us to around 
1us.  (I don't know why it works, but this isn't the only system we've 
seen that on)
I would love to have a small distro that just boots up and runs the app 
(EMC2 or some other RT app), and doesn't barf when you shut it down by 
removing power (without doing a shutdown).

Instead of porting the code our time might be better spent optimising
for x86 which would benefit all users.

My main question is how hard would it be to run EMC in a distributed
way so that the motion controller could run remotely from the pulse
generator?
  

I think the easier thing to do is put the motion controller and pulse 
generator on the same board, and let EMC2 run remotely the way it was 
designed - using NML or some other communication method at the CANON level.

- Steve


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-30 Thread Peter C. Wallace

 $300, using pluggable terminal strips ;)


Heh, We told Digikey the Avnet price and they came down to ~10.00...

For a parallel port replacement Ethernet, maybe a thing to consider is just a 
single point to point link to the (multi axis) endpoint and some very simple 
master slave protocol. The slave would get a packet, unpack to hardware 
registers, and echo a new packet or return data.

I've been thinking of doing this with a low cost FPGA card like the 7I43. Just 
replace the USB interface with a LM3S8933 or something (Nice because it has a 
built in PHY and IEEE 1588 (no speed demon though))


 - Steve


 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
()_() signature to help him gain world domination.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-30 Thread Rufi

Jon,

it will be in the $600 range for the emc community. like I said, we will not be 
developing the software so this will allow us to offer the board at a lower 
price.

regards,
Abdul



- Original Message 
From: Jon Elson [EMAIL PROTECTED]
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Sent: Tuesday, October 30, 2007 7:53:51 PM
Subject: Re: [Emc-users] Ethernet I/O

Rufi wrote:
 hello guys,
  
 I like to point you to our dspMC motion controller 
 www.vitalsystem.com/dspMC http://www.vitalsystem.com/dspMC. 
  
 the board has a blackfin DSP from Analog Devices.  the Blackfin dsp is 
 supported by Gnu/Gcc comipler and a linux port is available at 
 http://blackfin.uclinux.org.
Only $895

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-30 Thread Javid Butler

Fair enough, although I'm seeing machines that have both an RJ-45 and Wifi, 
which would address the problem.

Javid

- Original Message - 
From: Peter C. Wallace [EMAIL PROTECTED]
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Sent: Tuesday, October 30, 2007 8:17 PM
Subject: Re: [Emc-users] Ethernet I/O

 On Tue, 30 Oct 2007, Javid Butler wrote:

 Date: Tue, 30 Oct 2007 19:36:35 -0600
 From: Javid Butler [EMAIL PROTECTED]
 Reply-To: Enhanced Machine Controller (EMC)
 emc-users@lists.sourceforge.net
 To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
 Subject: Re: [Emc-users] Ethernet I/O

 Jon wrote-

 Given all the required overhead to read and write multiple
 packets, it is already pretty close to chewing up a whole
 millisecond, and there's no way it could handle even 5 KHz
 servo update rate.  So, I really don't think CAN is a good
 candidate.

 I agree. The thread started because of concern about the parport going 
 away
 on newer machines, and how to replace it. I have not seen any computers 
 with
 a CAN interface built in, which would defeat the whole purpose. We could
 consider USB, but that has problems as well and met with resistance
 upthread. Ethernet is relatively easy, affordable and available, and as 
 Jon
 mentioned before is isolated.

 Not arguing for CAN, but Ethernet being built-in is not a great advantage
 unless there are 2 channels built in, since real time Ethernet (real time
 meaning fast enough to close a servo loop) will not get along with normal
 Ethernet traffic and a network connection is almost a necessity, requiring 
 a
 add-in card in most cases. Not much different from the parallel port case,
 though faster.

 Peter Wallace

 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Stephen Wille Padnos wrote:
 
 Jon Elson wrote:
 
 

 
 I think the flash is actually slower than external memory access.  The 
 datasheet for one of these chips (don't remember which one) said that it 
 was limited to ~55 MHz operating from flash, but 175-200 MHz from RAM.  
 I don't recall if that was internal SRAM or external ram though.  It's 
 definitely prudent to stick high-speed ISRs in RAM though.
 
OK, I have read a LOT more about the unavailable NXP ARM7 chips 
with the 10/100 Ethernet built in, and haven't gotten up to 
speed on the Atmel version.
 
 There would need to be some 
process on the PC supporting file serving to the ARM, but I 
suppose NFS would work.  Without all the Linux OS overhead and 
virtual PC nightmares of the current PC architecture, the 70+ 
MIPS of the ARM processors might be sufficient.
 

 
 You don't need to serve files.  The place to put the break between PC 
 and motion controller is probably CANON/NML, not G-code.  This 
 eliminates the need to send G-code files to the embedded box, and it 
 also makes G-code additions/modifications happen on the PC only (most of 
 the time anyway).
 
Well, this is getting WAY deeper into this than I wanted it 
to get!  I was hoping for a quick hack to basically extend my 
IEEE-1284 protocol through some kind of ethernet encapsulation, 
now we're getting into splitting EMC2 into several pieces 
running on different architectures.  It would certainly be a 
great facility to have, but this way beyond the amount of time I 
have to devote to it.  If I could do some of the hardware level 
stuff, like reworking an Atmel development board to just have 
what we need (like maybe some outboard RAM, Ethernet, parallel
port that could be used for step generation or an interface to 
my controller boards, and the ADC and other features of the 
Atmel chip, I'd sure be interested in working on that.  But, 
when I look at all the areas that might need work, such as 
hooking RTnet (or other RT-Ethernet driver/stack) to HAL, 
getting the same RT-ethernet driver ported to the Atmel chip,
and now sawing EMC2 in half without killing it, just like the 
stage magician, I'm definitely getting overwhelmed.
 
Once the file serving question is handled, the only serious 
remaining effort (I think) would be porting rtapi to one of the 
competing ARM RTOS options.
 

 
 I don't know that the embedded processor needs to run Linux.  That may 
 be an unnecessarily large burden, though it seems simpler because you're 
 then just networking two Linux systems, which works quite nicely.  I 
 suspect, though I don't have any recent experience with it, that ucLinux 
 is pretty RT already, or could be made so pretty easily.
 
There are several Rtos packages for the ARM that are not 
anything near a Linux kernel.  They are much closer to the old 
rt scheduler.
 
A very interesting idea, but it could be fairly time consuming 
to deal with all the intricacies of such a big porting effort.
It would sure make a NEAT package, and the board could be quite 
cheap.  These ARM microcontrollers are in the $7 - 14 range, 
they need an additional $12 or so of parts to implement 
Ethernet, and maybe under $10 for extra memory.  I would think 
that pat could be done for under $100.  Add an FPGA to do step 
generation or PWM drive and a bunch of I/O connections, and you
are up to maybe $200 for a commercial product.
 

 
 $300, using pluggable terminal strips ;)
Yeah, I know!

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Peter C. Wallace wrote:
$300, using pluggable terminal strips ;)
 
 
 
 Heh, We told Digikey the Avnet price and they came down to ~10.00...
 
 For a parallel port replacement Ethernet, maybe a thing to consider is just a 
 single point to point link to the (multi axis) endpoint and some very simple 
 master slave protocol. The slave would get a packet, unpack to hardware 
 registers, and echo a new packet or return data.
Yes, but it has to have a real time driver module, that's the 
problem.  And, it would require two ethernet ports on the 
system, if you wanted to also be on the local network.
 
 I've been thinking of doing this with a low cost FPGA card like the 7I43. 
 Just 
 replace the USB interface with a LM3S8933 or something (Nice because it has a 
 built in PHY and IEEE 1588 (no speed demon though))
For what I want to do with t, it has to be pretty fast.  I'd 
want to leave the possibility it could run at a 10 KHz servo 
update rate, otherwise it is a step BACK from the parallel port.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Peter C. Wallace wrote:
 On Tue, 30 Oct 2007, Javid Butler wrote:

Date: Tue, 30 Oct 2007 19:36:35 -0600
From: Javid Butler [EMAIL PROTECTED]
Reply-To: Enhanced Machine Controller (EMC)
emc-users@lists.sourceforge.net
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Subject: Re: [Emc-users] Ethernet I/O

Jon wrote-

Given all the required overhead to read and write multiple
packets, it is already pretty close to chewing up a whole
millisecond, and there's no way it could handle even 5 KHz
servo update rate.  So, I really don't think CAN is a good
candidate.

I agree. The thread started because of concern about the parport going away
on newer machines, and how to replace it. I have not seen any computers with
a CAN interface built in, which would defeat the whole purpose. We could
consider USB, but that has problems as well and met with resistance
upthread. Ethernet is relatively easy, affordable and available, and as Jon
mentioned before is isolated.

 Not arguing for CAN, but Ethernet being built-in is not a great advantage 
 unless there are 2 channels built in, since real time Ethernet (real time 
 meaning fast enough to close a servo loop) will not get along with normal 
 Ethernet traffic and a network connection is almost a necessity, requiring a 
 add-in card in most cases. Not much different from the parallel port case, 
 though faster.
RTnet solves this problem by time division multiplexing the 
ethernet, but then you need some other machine to have the dual 
ethernet ports to work as a router.  But, you only need one.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-30 Thread Rafael Skodlar

Jon Elson wrote:
 Jarl Stefansson wrote:
   
 I would like to point out that ARM processors aren't the only way to go
 embedded, there are very decent x86 embedded systems available with AMD
 (Geode LX/NX) and VIA (CN/CX/C7/Eden) CPUs.

 
As others have pointed out, miniITX and such do not solve the problem 
because there is no appropriate IO available in most of them.

 System based on these can be sourced for less than $100 in bulk and as
 an added benefit none of the code needs to be ported.

 
 Unless you are going to put a hard drive on there, you still 
 have to problem of where the G-code files come from.
   
NFS. You don't need it much, only to copy the files to slave system from 
the server and you can disconnect the network afterwards for security or 
latency reasons.

There are other possibilities to go about this: http://www.emdebian.org, 
http://www.ltsp.org, or http://www.etherboot.org for example. Bootup 
takes only a few seconds so it would be possible to rebuild the whole OS 
and simply reboot the slave system. Other advantages are low initial and 
maintenance costs, one non-RT server could feed a number of diskless EMC 
systems on  the shop floor, etc. Default OS with basic EMC functionality 
could still be stored in EMC system flash memory.

Providing virtual appliances for bootup from the net and testing would 
also be easy with virtualization now being mainstream. Instead of 
generic EMC, a set of preconfigured appliances could be built to help 
new users.

 Perhaps it's time to experiment with building a custom distro to run
 EMC2 or a subset of it on embedded systems booting from flash NAND/NOR.

 
 I guess there are special file systems that reduce unneccesary 
 writes to the flash memory.  or, you could put all the writable 
 files on the system with the GUI.  Do these systems still have 
 parallel ports?  I'm guessing these systems still have VGA 
 ports, too, so you don't really need a separate system for the GUI.
   
 Instead of porting the code our time might be better spent optimising
 for x86 which would benefit all users.

 My main question is how hard would it be to run EMC in a distributed
 way so that the motion controller could run remotely from the pulse
 generator?
 
 Hmmm, well the MPG could still be connected to the system 
 running the RT section of EMC, but I'm not sure that's what you 
 are asking here.

 Jon
   
-- 
Rafael


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Erik Christiansen

On Fri, Oct 26, 2007 at 08:37:47PM -0500, Javid Butler wrote:
The real problem is the endpoint device. There will have to be some way to
decode the signals from the ethernet into the actual drives. It will
probably be a while before cost effective drives are available with ethernet
inputs. Until then we will have to use decoders that provide translation of
the ethernet commands to individual bits such as are on the parallel port.

Is it essential that it be ethernet? If Jon's custom host controller had
one or more RS485 ports (preferably 4-wire full-duplex), then any fast
microcontroller with one or more serial ports could potentially serve as
the endpoint controller.

With on-board multiple-channel PWM generators (e.g. with 64 MHz clock)
counter/timers to offload the CPU, and interrupt service routines being
the natural order, a reasonably fast uC can handle velocity feedback,
and calculating PID without too much fuss. (But high speed machine
control may be more demanding.)

Something like the AT90PWM3B, while only clocking 16 MIPS, needs only
H-bridges and drivers added, to control a BLDC from its on-chip
synchronised power stage controllers (specialised PWM). I haven't tried
the ready made card at
http://www.atmel.com/dyn/products/tools_card.asp?family_id=607family_name=AVR+8%2DBit+RISC+tool_id=3764
Estop can be fed directly into the output power stage controllers, if
desired.

The 100 MHz 8051 core also sounds interesting (as an axis controller)
from a hardware point of view, but it's famously mismatched for 'C'
coding, due to its stack limitations, and accumulator-centric
architecture. The (possibly consequential) lack of gcc support, is
probably the biggest hindrance to my eye, followed by the greater wealth
of on-board peripherals on competing products. (Having used it
professionally for nearly 2 decades, I have a soft spot for it, though.)

A distributed architecture appeals because it is easier to
upgrade/rebuild if the host controller only reads gcode and says go to
x, at speed s. There are no precison dc control voltages dodging EMI
from power electrics either. Incidentally, with eeprom as well as flash
in these microcontrollers, PID and other parameters can be stored in the
drive, and updated via the host. (No panicked search for old data files
when bringing a mothballed drive back into service.)

Trying to make the serial communications super-hard real-time could be
the hard way to do things. Where several axes need to be synchronised,
one axis controller can put its encoder pulsetrain directly onto an
RS485 synchronisation bus, and slaved axes feed that into on-chip
hardware counters, either interrupting when the count is big enough to
act on, or being read at the sample interval to check if the axis feed
ratio is being maintained. Especially at high speeds, with high encoder
line counts, a micro will still have to sample. (1 mS 16 MIPS = 16,000
instructions per interval)

The synchronising source can be chosen by selecting which axis
controllers send, and which receive on a bus. The synchronisation busses
would necessitate running a second cable between controllers, I figure.
(I have some cat5 cable and some oil-resistant metallic flexible
conduit, which I figured might do.)

Would a 64 byte packet be required to issue a motion command
to an axis controller, addressing included? (Since commands and status
reports need not be nanosecond realtime, now that sync is on separate
busses, does it hurt that an AT90PWM3B's 2Mb/s maximum baudrate extends
transfer time to 320 uS for 64 bytes?) Let's send 32 bytes. ;-)
Like the 8051, the AVRs have hardware address frame recognition, but
must compare addresses in software, so an RS422-style point-point
connection would be kinder.

If ethernet is used, it'd surely be necessary to be able to DMA the data
into the micro, or the benefit of 100 Mb/s would be lost. Now we'd need
an ARM chip as axis controller? Incidentally, if linux is to run on the
host, then ARM would be a better choice than the NXP beast? (Though
eCos is well endowed in the ISR area, and more suited to real-time.)

Erik

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Kenneth Lerman


What I had in mind is a DEDICATED ethernet segment. There would be no other
traffic on it other than our RT traffic.

I would NOT use UDP; I would use raw ethernet packets.

Ken

[EMAIL PROTECTED]
Mark Kenny Products Company, LLC
55 Main Street   Voice: (888)ISO-SEVO (888)476-7386
Newtown, CT 06470Fax: (203)426-9138
http://www.MarkKenny.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jon Elson
Sent: Sunday, October 28, 2007 10:44 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Ethernet I/O


Kenneth Lerman wrote:
 For me, the issue of RTnet is irrelevant. I would, instead, just want to
use
 the Linux driver. If we can get that to generate and receive ethernet
frames
 in real time, we are in business.

Well, that's the problem, it is NOT real time code.  I don't
know how far it is from being real time compatible, but I
suspect there's a lot of things in there that might cause
problems.
 Then we could let the PC be a master and any peripherals be slaves. In the
 case of the UPC board, there might be only one slave. The master would
poll
 each of the slaves as appropriate.
As long as you could throttle traffic on that ethernet segment,
so a network file transfer, for instance, couldn't bog down the
ethernet, then that would work.  But, I have no idea what would
be involved in making the ethernet port driver and network stack
RT compatible.  Some time ago the RT stuff didn't do anything
well except regularly-schenduled tasks, I think that is no
longar a problem.  But, the net driver would have to respond to
interrupts whenever a packet came in.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Kenneth Lerman

The issue is at the PC end.

In the past, parallel ports have been used, but it takes about a microsecond
per byte to output to them. Ethernet has the advantage is that the
controllers are PCI based and are a lot faster.

Ken

[EMAIL PROTECTED]
Mark Kenny Products Company, LLC
55 Main Street   Voice: (888)ISO-SEVO (888)476-7386
Newtown, CT 06470Fax: (203)426-9138
http://www.MarkKenny.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Erik
Christiansen
Sent: Monday, October 29, 2007 2:26 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Ethernet I/O


On Fri, Oct 26, 2007 at 08:37:47PM -0500, Javid Butler wrote:
 The real problem is the endpoint device. There will have to be some way to
 decode the signals from the ethernet into the actual drives. It will
 probably be a while before cost effective drives are available with
ethernet
 inputs. Until then we will have to use decoders that provide translation
of
 the ethernet commands to individual bits such as are on the parallel port.

Is it essential that it be ethernet? If Jon's custom host controller had
one or more RS485 ports (preferably 4-wire full-duplex), then any fast
microcontroller with one or more serial ports could potentially serve as
the endpoint controller.

With on-board multiple-channel PWM generators (e.g. with 64 MHz clock) 
counter/timers to offload the CPU, and interrupt service routines being
the natural order, a reasonably fast uC can handle velocity feedback,
and calculating PID without too much fuss. (But high speed machine
control may be more demanding.)

Something like the AT90PWM3B, while only clocking 16 MIPS, needs only
H-bridges and drivers added, to control a BLDC from its on-chip
synchronised power stage controllers (specialised PWM). I haven't tried
the ready made card at
http://www.atmel.com/dyn/products/tools_card.asp?family_id=607family_name=A
VR+8%2DBit+RISC+tool_id=3764
Estop can be fed directly into the output power stage controllers, if
desired.

The 100 MHz 8051 core also sounds interesting (as an axis controller)
from a hardware point of view,  but it's famously mismatched for 'C'
coding, due to its stack limitations, and accumulator-centric
architecture. The (possibly consequential) lack of gcc support, is
probably the biggest hindrance to my eye, followed by the greater wealth
of on-board peripherals on competing products. (Having used it
professionally for nearly 2 decades, I have a soft spot for it, though.)

A distributed architecture appeals because it is easier to
upgrade/rebuild if the host controller only reads gcode and says go to
x, at speed s. There are no precison dc control voltages dodging EMI
from power electrics either. Incidentally, with eeprom as well as flash
in these microcontrollers, PID and other parameters can be stored in the
drive, and updated via the host. (No panicked search for old data files
when bringing a mothballed drive back into service.)

Trying to make the serial communications super-hard real-time could be
the hard way to do things. Where several axes need to be synchronised,
one axis controller can put its encoder pulsetrain directly onto an
RS485 synchronisation bus, and slaved axes feed that into on-chip
hardware counters, either interrupting when the count is big enough to
act on, or being read at the sample interval to check if the axis feed
ratio is being maintained. Especially at high speeds, with high encoder
line counts, a micro will still have to sample. (1 mS  16 MIPS = 16,000
instructions per interval)

The synchronising source can be chosen by selecting which axis
controllers send, and which receive on a bus. The synchronisation busses
would necessitate running a second cable between controllers, I figure.
(I have some cat5 cable and some oil-resistant metallic flexible
conduit, which I figured might do.)

Would a 64 byte packet be required to issue a motion command
to an axis controller, addressing included? (Since commands and status
reports need not be nanosecond realtime, now that sync is on separate
busses, does it hurt that an AT90PWM3B's 2Mb/s maximum baudrate extends
transfer time to 320 uS for 64 bytes?) Let's send 32 bytes. ;-)
Like the 8051, the AVRs have hardware address frame recognition, but
must compare addresses in software, so an RS422-style point-point
connection would be kinder.

If ethernet is used, it'd surely be necessary to be able to DMA the data
into the micro, or the benefit of 100 Mb/s would be lost. Now we'd need
an ARM chip as axis controller? Incidentally, if linux is to run on the
host, then ARM would be a better choice than the NXP beast? (Though
eCos is well endowed in the ISR area, and more suited to real-time.)

Erik

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX

Re: [Emc-users] Ethernet I/O

Stephen Wille Padnos wrote:
 Jon Elson wrote:

As long as you could throttle traffic on that ethernet segment, 
so a network file transfer, for instance, couldn't bog down the 
ethernet, then that would work.

 
 No, it wouldn't (not necessarily).
 You'd also have to set the MTU pretty low.  A single UDP packet of 
 12.5kBytes takes 1ms to transmit on the wire.  (12.5k * 8 bits = 100 
 kbits = 1/1000 of 100 mbits/sec = 1msec)  Even if you throttle large 
 transfers, and you can somehow convince multiple hosts on the segment to 
 all share the same throttled pool of bandwidth, a single large packet 
 can throw a wrench in the works.
 
12.5 K bytes?  I've never run a system with an MTU greater than 
1536, I thought that was some generally agreed standard.  My 
current system has it at 1500.  1536 * 8 bits = 12288, at 100 
MBit/sec that would take 122 us plus overhead.  Better not let 
more than one of those packets through per millisecond.  That 
wouldn't really clobber the bandwidth for net transfers, though, 
you'd still get 1.5 MBytes/second throughput.  There would not 
be multiple hosts, just the CNC machine and whatever was acting 
as a router for it.  If you hooked a bunch of CNC control 
machines and their ethernet devices all on one segment, then 
you'd be asking for trouble.
 
 But, I have no idea what would 
be involved in making the ethernet port driver and network stack 
RT compatible.  Some time ago the RT stuff didn't do anything 
well except regularly-schenduled tasks, I think that is no 
longar a problem.  But, the net driver would have to respond to 
interrupts whenever a packet came in.
 

 
 I think the base for interrupt-response threads is there - the current 
 HAL thread mechanism uses it to grab the timer interrupt.  ADEOS can 
 route multiple interrupts (and multiple interrupt domains), and I'm 
 pretty sure RTAI also supports this.  It's just not part of RTAPI or HAL.
Yes, and I have no idea how hard it would be to put all that in. 
  HAL might not need to know about it at all, but it seems RTAPI 
would.  Now, maybe you could just start up the rtnet directly 
when the system boots, and let the drivers access rtnet without 
anybody else knowing its there.  I certainly don't know all the 
implications, it would take some study!

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Rafael Skodlar wrote:

 I would not want to rely on UDP for real time applications unless it's 
 used on an isolated network with a limited number of well behaving 
 nodes.
Yes, you would have to do it that way.

 
 Gigabit ethernet would be better but then which microcontroller will be 
 able to run with it? 32 bit only:
 http://www.freescale.com/webapp/sps/site/application.jsp?nodeId=0220502E112E1F
 
This gets quite expensive, at least for a while still.
 How about using some other bus for real time applications? I'm sure 
 there is a better bus for the price (CAN?)
I think CAN is much slower, and the hardware support is at a 
MUCH lower level.  It isn't much more sophisticated than a UART, 
thus software overhead.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Dave Engvall

Jon, Rafael, et al

IIRC CAN is 1 Mbit/sec.

Philosophically I'd opt for KISS. (keep it simple stupid).

No more complexity than is necessary to get the job done.

To me that sounds a lot like raw packets point to point.

Dave
On Oct 29, 2007, at 10:33 AM, Jon Elson wrote:

 Rafael Skodlar wrote:

 I would not want to rely on UDP for real time applications unless  
 it's
 used on an isolated network with a limited number of well behaving
 nodes.
 Yes, you would have to do it that way.


 Gigabit ethernet would be better but then which microcontroller  
 will be
 able to run with it? 32 bit only:
 http://www.freescale.com/webapp/sps/site/application.jsp? 
 nodeId=0220502E112E1F

 This gets quite expensive, at least for a while still.
 How about using some other bus for real time applications? I'm sure
 there is a better bus for the price (CAN?)
 I think CAN is much slower, and the hardware support is at a
 MUCH lower level.  It isn't much more sophisticated than a UART,
 thus software overhead.



 Jon

 -- 
 ---
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a  
 browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Erik Christiansen wrote:
 On Fri, Oct 26, 2007 at 08:37:47PM -0500, Javid Butler wrote:
 
The real problem is the endpoint device. There will have to be some way to 
decode the signals from the ethernet into the actual drives. It will 
probably be a while before cost effective drives are available with ethernet 
inputs. Until then we will have to use decoders that provide translation of 
the ethernet commands to individual bits such as are on the parallel port.
 
 
 Is it essential that it be ethernet? If Jon's custom host controller had
 one or more RS485 ports (preferably 4-wire full-duplex), then any fast
 microcontroller with one or more serial ports could potentially serve as
 the endpoint controller.
 
The idea is that 100 mbit/sec ethernet is fast.  What other 
RS485 device do you have that runs that fast?
 With on-board multiple-channel PWM generators (e.g. with 64 MHz clock) 
 counter/timers to offload the CPU, and interrupt service routines being
 the natural order, a reasonably fast uC can handle velocity feedback,
 and calculating PID without too much fuss. (But high speed machine
 control may be more demanding.)
 
The main idea of this discussion os to PRESERVE the mode of 
EMC2, and get around the disappearance of the parallel port.
There is no doubt that the entire motion control task, in fact 
all of EMC2 except the GUI, could be moved to one of these ARM 
micros.
And, by spoon-feeding the G-code in large chunks, there's be no 
need for a fast I/O channel.  But, that is not waht I was trying 
to do!

 If ethernet is used, it'd surely be necessary to be able to DMA the data
 into the micro, or the benefit of 100 Mb/s would be lost. Now we'd need
 an ARM chip as axis controller? Incidentally, if linux is to run on the
 host, then ARM would be a better choice than the NXP beast? (Though
 eCos is well endowed in the ISR area, and more suited to real-time.)
This is all handled by these ARM7 micros, they are an entire PC 
on one chip, except for video.  The NXP LPC2300 IS an ARM7 CPU. 
  They also have ARM9 if you need even more.  Their problem is 
getting working silicon out of the lab.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Andrew Ayre

CAN is indeed a maximum 1Mbps, however about 50% of that is overhead, so
the actual data bandwidth is more like a max of 500kbps. This is over a
distance of something like 40 meters.

CAN only defines the physical connection and message frame format. All
the bit stuffing, sync, acknowlegements and limited retransmits are
handled in hardware, but your application has to process messages that
arrive fast enough for your application. Nearly all CAN controllers
implement message filtering in hardware as well, reducing the number of
messages that your application has to process. There is a max of 8 bytes
in a message frame. The hardware implementation is quite a bit more
sophisticated than a UART.

Andy

Jon Elson wrote:
 Rafael Skodlar wrote:
 
 I would not want to rely on UDP for real time applications unless it's 
 used on an isolated network with a limited number of well behaving 
 nodes.
 Yes, you would have to do it that way.
 
 Gigabit ethernet would be better but then which microcontroller will be 
 able to run with it? 32 bit only:
 http://www.freescale.com/webapp/sps/site/application.jsp?nodeId=0220502E112E1F

 This gets quite expensive, at least for a while still.
 How about using some other bus for real time applications? I'm sure 
 there is a better bus for the price (CAN?)
 I think CAN is much slower, and the hardware support is at a 
 MUCH lower level.  It isn't much more sophisticated than a UART, 
 thus software overhead.
 
 Jon
 
 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users
 
 
 

-- 
Andy
PGP Key ID: 0x67090A54

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Peter C. Wallace

On Mon, 29 Oct 2007, Jon Elson wrote:
 The idea is that 100 mbit/sec ethernet is fast.  What other
 RS485 device do you have that runs that fast?

Of course a RS-485 link can have smaller packets, and may actually have much 
better real time performance. (a single 10 MBps RS-485 link will have much 
better performance than 100 BT Ethernet connected to a single encoder)

Also 100BT with its MLT3 encoding is not as electrically robust as isolated 
RS-485 or 10BT.

Ethernet is great for broadcast but I don't think so good for collecting data 
from a large number of separate real time devices (say encoders)

I think Ethernet would be a really good way to connect a multi channel motion 
controller to a PC where the large packet size is not such nuisance. You would 
likely need a separate Ethernet card from the main network connection.

Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
()_() signature to help him gain world domination.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Alex Joni

I really think all of the thread raised issues have been addressed by 
Ethercat:

1. it uses Ethernet (100MBps max) raw packages
2. there is an opensource Ethercat Master, which runs under linux/RTAI 
(http://www.etherlab.org/en/ethercat/index.php)
3. you could command motion and IO devices using one Ethercat network
4. Data for and from 100 servo axis can be updated with up to 10 kHz.
5. Process data exchange with 1000 distributed digital I/O takes about 30 
µs.
6. The packages are really simple packages, each device looks inside if 
there's anything for itself, otherwise the package gets passed on. Due to 
these features EtherCAT can support almost any topology such as line, tree 
or star. 
7. Since 100BASE-TX Ethernet physical layer is used, the distance between 
any two nodes can be up to 100 m (300 ft). Up to 65535 devices can be 
connected per segment. If an EtherCAT network is wired in ring configuration 
(requires two ports on the master device), it can provide cable redundancy.
8. For synchronization a distributed clock mechanism is applied, which 
leads to very low jitters of significantly less than 1 µs even if the 
communication cycle jitters. Therefore EtherCAT does not require a special 
hardware in the master device and can be implemented in software on any 
standard Ethernet MAC, even without dedicated communication coprocessor.
9. While the master can be implemented in software on the PC, EtherCAT 
slave controllers are available as code for different FPGAs and are also 
available as ASIC implementation.
10. Using ethercat one could drive the motors from HAL, and read back 
encoder information (this would assume 1-2 ethercat logical devices / axis). 
I (personally) would implement a single axis controller (analog output or 
stepgen, and encoder input) which can be commanded by Ethercat. Then you 
could join 2-9 of these, depending how many joints the machine has. For I/O 
I would use existing products for starters (e.g. from Beckhof).

Regards,
Alex

PS: most of the quotes are form http://en.wikipedia.org/wiki/EtherCAT

- Original Message - 
From: Jon Elson [EMAIL PROTECTED]
To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
Sent: Monday, October 29, 2007 7:44 PM
Subject: Re: [Emc-users] Ethernet I/O


 Erik Christiansen wrote:
 On Fri, Oct 26, 2007 at 08:37:47PM -0500, Javid Butler wrote:

The real problem is the endpoint device. There will have to be some way 
to
decode the signals from the ethernet into the actual drives. It will
probably be a while before cost effective drives are available with 
ethernet
inputs. Until then we will have to use decoders that provide translation 
of
the ethernet commands to individual bits such as are on the parallel 
port.


 Is it essential that it be ethernet? If Jon's custom host controller had
 one or more RS485 ports (preferably 4-wire full-duplex), then any fast
 microcontroller with one or more serial ports could potentially serve as
 the endpoint controller.

 The idea is that 100 mbit/sec ethernet is fast.  What other
 RS485 device do you have that runs that fast?
 With on-board multiple-channel PWM generators (e.g. with 64 MHz clock) 
 counter/timers to offload the CPU, and interrupt service routines being
 the natural order, a reasonably fast uC can handle velocity feedback,
 and calculating PID without too much fuss. (But high speed machine
 control may be more demanding.)

 The main idea of this discussion os to PRESERVE the mode of
 EMC2, and get around the disappearance of the parallel port.
 There is no doubt that the entire motion control task, in fact
 all of EMC2 except the GUI, could be moved to one of these ARM
 micros.
 And, by spoon-feeding the G-code in large chunks, there's be no
 need for a fast I/O channel.  But, that is not waht I was trying
 to do!

 If ethernet is used, it'd surely be necessary to be able to DMA the data
 into the micro, or the benefit of 100 Mb/s would be lost. Now we'd need
 an ARM chip as axis controller? Incidentally, if linux is to run on the
 host, then ARM would be a better choice than the NXP beast? (Though
 eCos is well endowed in the ISR area, and more suited to real-time.)
 This is all handled by these ARM7 micros, they are an entire PC
 on one chip, except for video.  The NXP LPC2300 IS an ARM7 CPU.
  They also have ARM9 if you need even more.  Their problem is
 getting working silicon out of the lab.

 Jon

 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


 -- 
 No virus found in this incoming message.
 Checked by AVG Free Edition.
 Version

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Peter C. Wallace

 I really think all of the thread raised issues have been addressed by
 Ethercat:

Umm, no... As master, no problem but slaves will be expensive:

Ethercat slaves require either custom proprietry hardware or proprietary IP

You can not use a generic ucontroller with Ethernet as a EtherCat slave.


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
()_() signature to help him gain world domination.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Alex Joni

 Umm, no... As master, no problem but slaves will be expensive:

 Ethercat slaves require either custom proprietry hardware or proprietary 
 IP

Hmm, unfortunately I can't argue there.. been trying to find some prices for 
a slave chip.
I found some products, but no prices anywhere:
 - beckhoff ET1100, ET1200
 - ESC10, ESC20
and some FPGA IP Core for Altera  Xilinx

Maybe you have an idea how expensive they are?

Regards,
Alex


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-29 Thread Kenneth Lerman


Is 100BaseT ethernet full duplex? (I think it is.)

In principle, one could make a hub (not technically a hub) that daisy
chained cables. So, the master would output to slave 1 abd input from slave
N. Slave 1 would input from the master and output to slave 2. Slave 2 would
input from slave 1 and output to slave 2... Slave N would input from slave
N-1 and output to the master.

Each slave would read its input, process it if appropriate and pass it on to
the next in the link. It would also inject its output into the ring.

Think of it as a token ring using ethernet hardware that is cheap and
readily available.

The master would continuosly send poll packets around the ring.

An alternative is to use a standard hub and have the master poll each of the
slaves, in turn.

I don't see this as something to use with encoders, but I could imagine its
being used with smart motor controllers or multi-axis controllers (like
Jon's).

Ken

[EMAIL PROTECTED]
Mark Kenny Products Company, LLC
55 Main Street   Voice: (888)ISO-SEVO (888)476-7386
Newtown, CT 06470Fax: (203)426-9138
http://www.MarkKenny.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Peter C.
Wallace
Sent: Monday, October 29, 2007 2:16 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Ethernet I/O


On Mon, 29 Oct 2007, Alex Joni wrote:

 Date: Mon, 29 Oct 2007 21:00:22 +0200
 From: Alex Joni [EMAIL PROTECTED]
 Reply-To: Enhanced Machine Controller (EMC)
 emc-users@lists.sourceforge.net
 To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net
 Subject: Re: [Emc-users] Ethernet I/O

 Umm, no... As master, no problem but slaves will be expensive:

 Ethercat slaves require either custom proprietry hardware or proprietary
 IP

 Hmm, unfortunately I can't argue there.. been trying to find some prices
for
 a slave chip.
 I found some products, but no prices anywhere:
 - beckhoff ET1100, ET1200
 - ESC10, ESC20
 and some FPGA IP Core for Altera  Xilinx

 Maybe you have an idea how expensive they are?


No, I looked into this several months ago but was discouraged by the
hardware requirements. For the sychronization standards, I have more faith
that IEEE 1588 will get embedded in more Ethernet chips and processors with
Ethernet, for example:
Ethernet Transceiver with IEEE 1588 PTP Hardware Support from National Semi
(Product News, 17 Oct 2007 )

National Semiconductor has introduced its Ethernet transceiver with
integrated
hardware support for the IEEE 1588 Precision Time Protocol (PTP). For
applications in motion control, instrumentation, data acquisition and
telecommunications, the DP83640 precision PHYTER transceiver synchronizes
the
distributed network nodes to a master clock with 8-nanosecond accuracy.


The model DP83640 precision PHYTER transceiver synchronizes distributed
network nodes to master clock with 8 nsec accuracy and offers 100 Mb
synchronous Ethernet mode that eliminates any inaccuracy caused by clock
drift
between nodes. It integrates hardware time stamping of receive and transmit
packets, high-accuracy IEEE 1588 clock, and 12 GPIO pins that handle
simultaneous real-time events/multiple triggers. Device interfaces with any
microcontroller, FPGA, or ASIC with Ethernet MAC. The samples of the DP83640
transceiver are available now in a 48-pin LQFP. The DP83640 will be priced
at
$5.24 each in 1,000-unit quantities.







 Regards,
 Alex


 -
 This SF.net email is sponsored by: Splunk Inc.
 Still grepping through log files to find problems?  Stop.
 Now Search log events and configuration files using AJAX and a browser.
 Download your FREE copy of Splunk now  http://get.splunk.com/
 ___
 Emc-users mailing list
 Emc-users@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/emc-users


Peter Wallace
Mesa Electronics

(\__/)
(='.'=) This is Bunny. Copy and paste bunny into your
()_() signature to help him gain world domination.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https

Re: [Emc-users] Ethernet I/O

Peter C. Wallace wrote:
 On Mon, 29 Oct 2007, Jon Elson wrote:
 
The idea is that 100 mbit/sec ethernet is fast.  What other
RS485 device do you have that runs that fast?
 
 
 Of course a RS-485 link can have smaller packets, and may actually have much 
 better real time performance. (a single 10 MBps RS-485 link will have much 
 better performance than 100 BT Ethernet connected to a single encoder)
 
 Also 100BT with its MLT3 encoding is not as electrically robust as isolated 
 RS-485 or 10BT.
 
 Ethernet is great for broadcast but I don't think so good for collecting data 
 from a large number of separate real time devices (say encoders)
 
Yes, I think this would be a bad way to do things.  Having a 
single motion control board that interfaces by Ethernet, as I 
have been envisioning, would have a lot of advantages.  It keeps 
the sampling of all the encoders synchronized, it compresses all 
the information interchange into a couple packets, it saves on 
hardware.  Putting a separate ethernet interface into each 
encoder is a great way to sell a lot of hardware.
 I think Ethernet would be a really good way to connect a multi channel motion 
 controller to a PC where the large packet size is not such nuisance. You 
 would 
 likely need a separate Ethernet card from the main network connection.
RTnet, for instance, gets around this to some extent.  But, that 
is one way to do it, have 2 ethernet ports on the computer, one 
for RT, one for the local net.  Otherwise some kind of router 
needs to be used to keep outside traffic from flooding the RT 
segment.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Kenneth Lerman wrote:
 Jon,
 
 You suggest that the PC would request the registers from the IO board and
 the IO board would respond with the requested registers. How much delay,
 jitter, latency,... is acceptable?
 
Darn good question.  I know the jitter on when the current 
parport interface requests the encoder counter to be sampled is 
less than 5 us, almost all in rt scheduler task switch overhead.
I have no idea what sort of latency or jitter one would get with 
the rtnet and ethernet hardware.
 The processor could send a new command every servo cycle. On receipt of the
 command, the IO board could then send the current registers to the PC AND
 process the command. The PC would use those registers to compute the next
 command.
 
Yes, this actually has some merit :  hold back the next velocity 
update until the NEXT servo cycle, and update velocity as you 
ask for current position.  The PPMC (analog 10 V interface) 
actually does this in hardware, the last output from the PID 
loop is sent to the DAC chip's registers as soon as it is ready, 
but the DAC does not update to the analog output until the next 
sampling of the encoder counters.  This is also how my 
Allen-Bradley 7320 implemented the servo cycle.

And, it reduces the number of messages by 33%, which sounds good.
 There will always be a delay between reading the registers and generating a
 new command. Is the delay using this scheme too long? Can the software
 compensate for the delay? Given the current velocity and the time delay, we
 could compute a projected position. Given the velocity, acceleration, and
 time delay, we could do even better.
 
By reducing to the 2-message scheme, then as long as the delay 
is less than a full servo cycle (minus network latency) there is 
no problem.
 This approach would save one packet. More importantly, the PID calculation
 could take more time. In fact, it could use the essentially the entire servo
 cycle time. That would let us increase the servo rate.
 
Yes, that is part of the idea here is to be able to up the servo 
rate.  I'm not sure it will actually accomplish that, though, 
depending on the network delays.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Javid Butler wrote:
 Jon-
 
 The Silicon Labs chip is not a typical 8051. You are correct about a 
 standard 8051, but this chip is more of an 8051 core running at 50 or 100 
 MHz. They may have a version with an Ethernet MAC and DMA as well.
 
 Which ARM7 are you looking at? Atmel has some good ones, and I know some 
 people who are using Freescale for embedded ethernet products. There are a 
 lot of good ARM7 processors out there.
I started looking at the NXP LPC2368 series, but these have not 
been available for a while.  Now I am looking at the Atmel 
AT91SAM7X256.  It is in a 100-pin LQFP package, which is going 
to be easy to mount.  I want to avoid BGAs.  The NXP chips 
started at about $7, the Atmel is a little more expensive, 
around $10.  Either one is still a GREAT deal for what you get!
The NXP chip is supposed to run at 72 MHz, but there were 
problems when it ran that fast.  I think the Atmel is a little 
slower, but still probably a lot faster than an 8-bit CPU at 
even 100 MHz.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

Jon Elson wrote:
 Stephen Wille Padnos wrote:
  You can't use any old
topology with RTNet.  RTNet is a TDMA scheme - each device gets a time 
slot in which it may transmit.  This eliminates collisions, which are 
the main cause of timing jitter on ethernet.
Well, after some more reading of the RTnet documents, I'm not 
sure that rtnet is really appropriate for this project.  The 
biggest problem is that I have no rtnet driver for the slave 
device.  Depending on the way the ethernet stack has been 
written for the ARM7 chips I'm looking at using, it could be 
anywhere from difficult to nearly impossible to implement RTnet 
on these microcontrollers.  Now, maybe I am underestimating the 
sophistication of how these stacks are constructed, and it might 
be quite straightforward to port RTnet to the ARM7 with built-in 
ethernet MAC.  I think this is way beyond my level of expertise.

One thing I couldn't figure out from the RTnet docs what what 
the rate of the schedule frames is.  I guess it matters what bit 
rate the media is running at, and packet size, number of nodes, 
etc.  I was just trying to figure out what these rates might 
come out to.  As long as a router would throttle any incoming 
traffic, this particular application doesn't actually require 
all the features of RTnet.  If the problem of porting the RTnet 
driver to non-PC, non-Linux systems can be solved, then it 
certainly will work.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-28 Thread Kenneth Lerman


For me, the issue of RTnet is irrelevant. I would, instead, just want to use
the Linux driver. If we can get that to generate and receive ethernet frames
in real time, we are in business.

Then we could let the PC be a master and any peripherals be slaves. In the
case of the UPC board, there might be only one slave. The master would poll
each of the slaves as appropriate.

Ken

[EMAIL PROTECTED]
Mark Kenny Products Company, LLC
55 Main Street   Voice: (888)ISO-SEVO (888)476-7386
Newtown, CT 06470Fax: (203)426-9138
http://www.MarkKenny.com


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Jon Elson
Sent: Sunday, October 28, 2007 4:43 PM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] Ethernet I/O


Jon Elson wrote:
 Stephen Wille Padnos wrote:
  You can't use any old
topology with RTNet.  RTNet is a TDMA scheme - each device gets a time
slot in which it may transmit.  This eliminates collisions, which are
the main cause of timing jitter on ethernet.
Well, after some more reading of the RTnet documents, I'm not
sure that rtnet is really appropriate for this project.  The
biggest problem is that I have no rtnet driver for the slave
device.  Depending on the way the ethernet stack has been
written for the ARM7 chips I'm looking at using, it could be
anywhere from difficult to nearly impossible to implement RTnet
on these microcontrollers.  Now, maybe I am underestimating the
sophistication of how these stacks are constructed, and it might
be quite straightforward to port RTnet to the ARM7 with built-in
ethernet MAC.  I think this is way beyond my level of expertise.

One thing I couldn't figure out from the RTnet docs what what
the rate of the schedule frames is.  I guess it matters what bit
rate the media is running at, and packet size, number of nodes,
etc.  I was just trying to figure out what these rates might
come out to.  As long as a router would throttle any incoming
traffic, this particular application doesn't actually require
all the features of RTnet.  If the problem of porting the RTnet
driver to non-PC, non-Linux systems can be solved, then it
certainly will work.

Jon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-28 Thread Javid Butler



 For me, the issue of RTnet is irrelevant. I would, instead, just want to 
 use
 the Linux driver. If we can get that to generate and receive ethernet 
 frames
 in real time, we are in business.

 Then we could let the PC be a master and any peripherals be slaves. In the
 case of the UPC board, there might be only one slave. The master would 
 poll
 each of the slaves as appropriate.

 Ken

That is the way the ACN protocols work, although they operate with a more 
peer-to-peer structure. ACN rides on top of Internet Protocol, so the 
standard Linux driver should work fine. If a device has something to say it 
just says it, and everyone who wants to listen does. This does not increase 
bandwidth consumption and may decrease it because there is no need for the 
controller to ask a responder for information. When looking at things like 
encoders transported in an uncompressed format over ethernet this is the 
most bandwidth efficient method. Compressed or interpreted data are 
similarly efficient.

Let me illustrate with a stepper motor:
Simple Controller: Move +1 step X
Simple Drive: Moved +1 step X
Messages sent until final position reached. This is the direct ethernet 
equivalent of the parallel port

Medium Controller: Move +1000 steps X
Medium Drive: Moved +1000 steps X
One message sent to move 1 (.001 step resolution).

For compound moves either the drive or the controller becomes more 
complicated in the medium solution, so at this point what I would suggest is 
to aim for a medium solution for single axis moves that switches down to the 
simple method for compund moves. This should be relatively easy to code at 
the EMC end and almost brainless at the drive end. ACN structures already 
accomodate the different data types.

Advanced controllers are a more involved discussion.

I will edit the streaming ACN packet structure and post it to the list.

Thanks,
Javid





-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-28 Thread Stephen Wille Padnos

Javid Butler wrote:

For me, the issue of RTnet is irrelevant. I would, instead, just want to 
use
the Linux driver. If we can get that to generate and receive ethernet 
frames
in real time, we are in business.

Then we could let the PC be a master and any peripherals be slaves. In the
case of the UPC board, there might be only one slave. The master would 
poll
each of the slaves as appropriate.

Ken


That is the way the ACN protocols work, although they operate with a more 
peer-to-peer structure. ACN rides on top of Internet Protocol, so the 
standard Linux driver should work fine. If a device has something to say it 
just says it, and everyone who wants to listen does. This does not increase 
bandwidth consumption and may decrease it because there is no need for the 
controller to ask a responder for information. When looking at things like 
encoders transported in an uncompressed format over ethernet this is the 
most bandwidth efficient method. Compressed or interpreted data are 
similarly efficient.

Let me illustrate with a stepper motor:
Simple Controller: Move +1 step X
Simple Drive: Moved +1 step X
Messages sent until final position reached. This is the direct ethernet 
equivalent of the parallel port

Medium Controller: Move +1000 steps X
Medium Drive: Moved +1000 steps X
One message sent to move 1 (.001 step resolution).

For compound moves either the drive or the controller becomes more 
complicated in the medium solution, so at this point what I would suggest is 
to aim for a medium solution for single axis moves that switches down to the 
simple method for compund moves. This should be relatively easy to code at 
the EMC end and almost brainless at the drive end. ACN structures already 
accomodate the different data types.
  

Could you provide an example of a servo motor with feedback?

I believe the main thing keeping EMC2 from using these non-RT 
communication links is that we have kept the motion controller on the 
PC.  This includes PID and feedback, which is what imposes the realtime 
requirements.  In the case of a stepper motor, or a velocity servo drive 
with its own PID, the PC can precompute some number of motions and 
download them as a block.  If you include feed override, especially 
adaptive feed override (which runs in realtime, and is intended to be 
used for things such as EDM and plasma machines), then you make it 
impossible to use a non-realtime communications scheme.  All motors 
*must* slow down not only synchronously, but in response to 
non-PC-generated data (such as a gap voltage sensor for EDM).  A simpler 
and more common example of this is spindle-synchronized motion (though 
the response latency may be more forgiving in that case).

Advanced controllers are a more involved discussion.
  

Arbitrarily advanced, you could say :)  We could of course stick a 
mini-EMC2 on each controller ...

I will edit the streaming ACN packet structure and post it to the list.
  

The wiki may be a better place, since we'd probably like the ability to 
revise it, and to keep track of revisions.
Just follow the instructions at 
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BasicSteps to add a page.

Thanks,
Javid
  

Thanks
- Steve


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O

2007-10-28 Thread Javid Butler

 Could you provide an example of a servo motor with feedback?

I will try, but all my machines are stepper driven, so while I think I 
understand the concept of a servo drive I've never tuned one or worked with 
it directly. Feel free to correct any misunderstandings. I'm using arbitrary 
dimensions for the sake of example.

Controller: set X velocity to 0.1
Drive: X velocity 0.1, position 0
Drive: X velocity 0.1, position 0.05
Controller: set X velocity to 0.2
Drive: X velocity 0.2, position 0.1
Controller: set X velocity to 0.1
Drive: X velocity 0.1, position 0.2
Drive: X velocity 0.1, position 0.25
Controller: set X velocity to 0
Drive: X velocity 0, position 0.3

For synchronous motor drive the feedback would need to be velocity and 
spindle angle and position.


snip
If you include feed override, especially
adaptive feed override (which runs in realtime, and is intended to be
used for things such as EDM and plasma machines), then you make it
impossible to use a non-realtime communications scheme

Basic feed override is easy-the new block is sent to the drive with a new 
rate or velocity. A rapidly changing rate override will require a number of 
packets. Adaptive would be a bit harder because it would require 
synchronized input.

ACN is designed for realtime control. It does this through sequencing rather 
than time domain multiplexing. Either strategy does have a maximum 
bandwidth. Sequencing has a higher potential bandwidth, but the maximum will 
vary based on the load. The drive will have to use a time domain software 
loop, but as long as the sequenced messages arrive faster than the loop 
cycle time it will not affect the synchronicity of the system-messages 
arriving before they are needed just get saved for the next cycle. With 
10-BaseT this could cause problems, but 100-BaseT should be OK.

In practical application the protocol layer will self-synchronize with the 
software loop in the drive, since controller actions depend on feedback.

snip

Advanced controllers are a more involved discussion.


 Arbitrarily advanced, you could say :)  We could of course stick a
 mini-EMC2 on each controller ...

That is what makes arbitrarily advanced controllers a more involved 
discussion. :)

How much of EMC2 to put in the drive, porting issues to microcontrollers 
with various architectures, these could be loong discussions. We started 
working on ACN around 1998. It was published in 2006.

Embedded EMC2 (EEMC2? E squared MC2? the latter sounds like a formula...) is 
definitely worth discussion, I just didn't want to start there.

Thanks,
Javid



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now  http://get.splunk.com/
___
Emc-users mailing list
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Re: [Emc-users] Ethernet I/O