RE: What to use? EtherCAT or Ethernet Powerlink with CANopen protocol

Hi all,
I want to thanks everybodybut, I'm sorry, I think my question was not
clearly introduce.
1.    Despite any PLC can NOT be deterministic because it depends on the
"branch" it executes the program (Soft Real Time).
It will be completely diferent to start an equation with an IF condition
that is not done or it's done, lasting more time if the PLC skip this
equation immediatly at the begining or if it has to execute many AND/OR
sub-equations. So the PLC's program executes an infinite loop that depends
on the I/Os and its own internal state.
2.    Let me explain a litlle what a CNC must do for sure deterministically
(I think this was the problem, nobody knows in detail):
Each TICK (e.g. 1 ms) must supply the "next" position (by R-PDO telegram) to
be achieved for all the axis are interpolating. In Absolute coordinates, it
represents 4 bytes per each axis, or 2 bytes in Incrementals. Furthermore,
each axis connected must "report" at least the position where it is (4 bytes
in Absolutes o 2 in Incremental) and its Status (2 bytes minimun) including
alarm code that could be later detailed by an SDO telegram. On this escenary
of a 4 axis machine ...
The sentence (extracted from the Sercos Field Bus competitor):
			"Simple CAN bus resources are quite poor on
applications that needs Real Time performances".

How to solve this important problem? Let's see how we did (www.inavcnc.com).

As we already mention, the strongest limitation is 1Mb/s=1000bits/ms.
Any CAN message has a length of 51 bits + 8 * No of Bytes per message (for a
CAN 2.0a with an "interframe space" of 7 bits). That is, 115 bits/telegram
for an 8 bytes message, 99 bits/telegram for a 6 bytes message 65
bits/telegram for a 2 bytes message and 51 bits/telegram for an 0 bytes
message. 
Master PDO (R-PDO) will be named as m_Cmd and the Slaves PDO (T-PDO) that
are the return messages of any Servo Drive Amplifier connected as m_Ret.
CANopen accepts to multiplex in the same PDO the command for 4 axis (we used
this very important performance!) 
Return messages (or Return telegrams) can use a lot of CANbus resources
increasing notably the traffic on the Bus and could produce a CANbus
overhead keeping on mind that a TICK of 1ms is our target.
We have fixed that m_Ret will be sent when m_Sync is received.
As it was mentioned earlier, each CANbus channel can control up to 4 axes
per 1 millisecond, representing:
1.-           m_Sync                                                 51 bits
2.-           m_Cmd (for 4 axes: named as X,Y,Z,C)                   115
bits
3.-           m_Ret (Axis X)                                         115
bits (8 bytes) or 99 bits (6 bytes)
4.-           m_Ret (Axis Y)                                         115
bits (8 bytes) or 99 bits (6 bytes)
5.-           m_Ret (Axis Z)                                         115
bits (8 bytes) or 99 bits (6 bytes)
6.-           m_Ret (Axis C)                                         115
bits (8 bytes) or 99 bits (6 bytes)
7.-           m_Req (Async. Telegram or T-SDO)                       115
bits
8.-           m_Res (Async. Telegram or R-SDO)                       115
bits
TOTAL in worst case:                856 bits/ms   or   792 bits/ms

IMPORTANT NOTE: CANbus has NOT ENOUGH SPACE FOR FURTHER INFORMATION (4 axis
more and the Inputs and Outputs).
8 telegrams =856 bits (so, balanced 144 microseconds could be uses to
increase any needed "interframe space" before the m_Sync has been send). It
can be noted that 8 axes with the same CANbus line is completely impossible
in the case that m_Ret of 6 or 8 bytes has been used.

m_Req and m_Res on normal conditions (interpolation) should not be use. Only
they will be used when the Servo Drives Amplifiers are disabled in order to
change or initialize some determines parameters. On our application we use
mainly Async Telegrams for:
a)                  Enable /disable the Servo Drives.
b)                  For the Zero Datum Point Search Procedure.
c)                  For Touching and/or collision Procedure. 
d)                  Emergency and Alarm Procedures.
Also, the use of 2 different m_Sync message types could be used to CHANGE ON
THE FLY the PID GAINS (for EDM and LASER) or the Electronic Gearbox and/or
Electronic CAM (for Printing and Packaging Machines), etc.

With respect m_Ret (its synchronous reception will serve to the CNC to know
the Servo Drive Amplifier is "alive"):
1.                    We discarded the Speed Return. Reason: they would be
used for the CNC as Oscilloscope signal and any more. On first commissioning
could be used, but in that case, we believe we could do a utility that
asynchronously demands those values each predetermined time. 
2.                    In some axes, we could use Torque Return in order to
know the consumption of the motor (tool is broke or wasted or ...). That
represents 2 bytes on the m_Ret telegram.
3.                    Incremental or Absolute Return Position would be used
to "control" if the servo is working properly.  We use the Real Absolute 16
bits Position in order to control the trailing error (or "Following
Distance" named too) just to produce an alarm. That represents 2 bytes more
on the m_Ret telegram. 
4.                    Servo Drive's status. That is the only relevant and
important Synchronous Information (all other can be perfectly omitted if the
Position Loop is in the Servo Drive Amplifier. That represents 2 bytes more
on the m_Ret telegram.
From the point of view of the Real Time, we are applying all is presented on
this paragraph in Servo Drives that implement CANbus with absolutely no
problem.
 
Anyhow, our query was to demand your opinions when we need to control more
axis and all the I/Os (digital and analog) with a single field bus channel?
That is because we are thinking in EtherCat or Powerlink (despite that I
sincerely believe that Ethernet hardware will win to any other solution in
the CNC market).
Hope I have clarify properly
Best,
Albert Saenz
Skype: my_voip

 
 


________________________________

De: [email protected]
[mailto:[email protected]] En nombre de Steinhoff
Enviado el: viernes, 14 de diciembre de 2012 9:30
Para: [email protected]
CC: [email protected]
Asunto: Re: [CANLIST] What to use? EtherCAT or Ethernet Powerlink with
CANopen protocol


[email protected] wrote:


	
	Hello,
	
	The module without power supply does not bypass, but the previous
device (from master point of view)
	does. Of course all the devices "after" the one without power supply
disappear but all the devices
	"before" remain active.
	
	Powerlink behaves similarly as long as the internal cut-through
switch is sharing same power supply
	with the rest of the device.
	


Yes ... but this is specific for the physical implementation of such a
module and the bus.
Hot swap of modules are always possible with Ethernet Powerlink if the
physical bus structure is a clean bus
without inter module dependencies.

But have in mind also a hub could be a single point of failure ... but this
wouldn't stop the whole system.

Hower ... what behavior is acceptable depends on the application.
The behavior of EtherCAT could be optimal if you have to control the
material flow over several convayers e.g.

Regards

--Armin



	
	This behavior is a consequence of using full-duplex Ethernet
physical layer instead of bus-type
	physical layer, e.g. CAN or coaxial-Ethernet.
	
	Best regards,
	
	-H
	
	
	
	
	
	Steinhoff
	
	
		
		From:        Steinhoff <[email protected]>
<mailto:[email protected]> 
	To:        [email protected]
	Cc:        [email protected]
	Date:        11.12.2012 13:41
	Subject:        Re: [CANLIST] What to use? EtherCAT or Ethernet
Powerlink with CANopen protocol
	Sent by:        [email protected]	


________________________________




	[email protected] <mailto:[email protected]> wrote:
	
	Gentlemen,
	
	From logical point of view, EtherCAT is a ring, but each device has
an ability to bypass
	connected physical segment if it is down. 
	
	That's only partly true. If the power supply is broken of the
errornous module it doesn't bypass anything.
	Yes ... if one module is broken there is the possibility to split
the initial ring into two rings ... but this works just for one broken
module.
	
	--Armin
	
	Physically EtherCAT networks can form any
	kind of topology.
	
	Powerlink follows standard Ethernet physical layer and if other than
star topology is
	required, hubs are needed. In practice, "hubs" are actually
cut-through type switches.
	Logical operation of Powerlink is based on a managing node
requesting controlled
	nodes to transmit point-to-multipoint packets.
	
	Redundant masters are challenging in any technology, even in
CAN-based CANopen,
	where change of effective NMT-master expects NMT-reset. However, in
CAN-based
	CANopen networks all transmissions can be asynchronous and
NMT-master blackout
	does not necessarily introduce any effect on the process signaling.
	
	On the contrary, master-node needs to trigger all transmissions in
both EtherCAT and
	Powerlink networks.
	
	Best regards,
	
	-H
	
	
	
	
	Steinhoff
	
		
		From:        Steinhoff <[email protected]>
<mailto:[email protected]> 
	To:        'CANLIST' <[email protected]>
<mailto:[email protected]> 
	Cc:        Albert Saenz <[email protected]>
<mailto:[email protected]> 
	Date:        11.12.2012 11:33
	Subject:        Re: [CANLIST] What to use? EtherCAT or Ethernet
Powerlink with CANopen protocol
	Sent by:        [email protected]
<mailto:[email protected]> 	

	
	
	
________________________________

	
	
	
	Albert Saenz wrote:
	> Hi all,
	> My first participation!
	> I know that perhaps it is not the best forum, but in any case I
believe many
	> of you have the same problem nowadays.
	> Despite CAN bus is a nice and powerful field bus (I like very much
compared
	> with any similar industrial bus), we'd need to improve notably the
speed (1
	> Mbit/s is clearly not enough even multiplexing the 8 bytes
telegrams at
	> R-PDO and minimizing all T-PDO). Bandwidth for Hard Real Time
applications
	> were the Tick should be less than 1 ms and massive I/Os and Motion
Drivers
	> should be controlled (typical CNC application) can not be limited
by the 1
	> Mb/s (even using multiple channels: 2 or more CAN buses, as our
applications
	> is using nowadays. 1 for I/Os and 1 o 2 more for control 4 or 8
axis with a
	> tick of 1 ms). In case we need "multi-channel" (i.e. 2 or more
independent
	> CNCs running at the same platform), CAN bus drastically limits and
it makes
	> no sense in many application.
	> My question is (requesting opinions):
	> CANopen protocol is supported by EtherCAT (ETG group) and Ehernet
Powerlink
	> (EPGS group) and that simplify migration from CAN bus (or we could
even
	> share both).
	
	The topology of the fieldbus must fit to your application.
	
	EtherCAT is based on a ring topology ...  EVERY I/O module must
transmit 
	every single bit throughout the ring.
	That means every I/O module could be a single point of failure .. 
	EtherCAT is also bound to the transmission speed of 100Mbit/s.
	Fault tolerant master configurations (hot standby a.s.o) are hard to

	realize .. or nearly impossible.
	
	Ethernet Powerlink has a clean bus topology ... there are also
master 
	nodes based on co-processor boards which allows to run the bus 
	independent from the load of the PC CPU.
	A problem with a single I/O module can't stop the bus. Ethernet 
	Powerlink isn't bound to 100Mbit/s.
	Fault tolerant configuration are easy to realize because of the
clean 
	bus topology.
	
	--Armin
	
	
	
	
	> I would like to know Guru's opinion and those are many of you.
	> Thanks in advance for your contribution,
	>
	> Albert Saenz
	> Sant Cugat del Valles - Barcelona
	>
	> --
	> Archives and useful links: http://groups.yahoo.com/group/CANbus
<http://groups.yahoo.com/group/CANbus> 
	> Subscribe and unsubscribe at www.vector.com/canlist/
	> Report any problems to <[email protected]>
<mailto:[email protected]> 
	>
	
	--
	Archives and useful links: http://groups.yahoo.com/group/CANbus
<http://groups.yahoo.com/group/CANbus> 
	Subscribe and unsubscribe at www.vector.com/canlist/
	Report any problems to <[email protected]>
<mailto:[email protected]> 
	
	
	
	This e-mail is confidential and it is intended only for the
addressees. Any review, dissemination, distribution, or copying of this
message by persons or entities other than the intended recipient is
prohibited. If you have received this e-mail in error, kindly notify us
immediately by telephone or e-mail and delete the message from your system.
The sender does not accept liability for any errors or omissions in the
contents of this message which may arise as a result of the e-mail
transmission. 
	
	
	
	This e-mail is confidential and it is intended only for the
addressees. Any review, dissemination, distribution, or copying of this
message by persons or entities other than the intended recipient is
prohibited. If you have received this e-mail in error, kindly notify us
immediately by telephone or e-mail and delete the message from your system.
The sender does not accept liability for any errors or omissions in the
contents of this message which may arise as a result of the e-mail
transmission. 
	


Se certifico que el correo entrante no contiene virus.
Comprobada por AVG - www.avg.es
Version: 9.0.930 / Base de datos de virus: 2634.1.1/5456 - Fecha de la
version: 12/14/12 01:25:00



--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector.com/canlist/
Report any problems to <[email protected]>