Discussion:
RTNET servo drive
(too old to reply)
m***@hetnet.nl
2017-02-05 14:37:08 UTC
Permalink
Raw Message
I've been working on an ethernet controlled servo drive for some time now.
This drive uses RTNET and Xenomai-3.0.3 for the real-time communication.
The current control loop is on the drive, but the position control loop
is on the PC.

Currently only tree motor types are supported, being Mitsubishi MF-S13
Mitsubishi HC-PQ-[24]3 and the Osai DS-56. The Osai motor uses a
Hiperface encoder, so supporting another motor with Hiperface should be
a simple change of the encoder offset and number of poles.

Since the drives have to be synchronised to the PC it is important to
reduce the jitter to the drives. To do this I have made two modifications
to the uspace_xenomai interface. The first is that a posix timer is used
to generate the control frequency. The second is that the real-time
synchronisation function needs access to this timer. (Eventually this
has to be replaced by PTP)

Another change has to do with permissions, I'm not sure what the proper
fix is so there's a hack in there to do everything as root.

The sources for the drive are at:
https://github.com/mark-v-d/motor_control.git

The patched linuxcnc version is at:
https://github.com/mark-v-d/linuxcnc.git

Please keep in mind this is all work in progress. The hardware needs
a few patches (notes in the schematic) and the software is nowhere near
complete. As soon as I've got everything working I'm going to make another
drive which works at 600V, and support at least the AEAT-6010/6012
and AEAT-9000-1GSH1 encoders.

regards,

Mark.
Rene Hopf
2017-02-05 20:33:41 UTC
Permalink
Raw Message
Hi,
Interesting Project!
Im also working on a servo amp which supports hiperface, mitsubishi abs encoders, and many other protocols, and also resolvers.
https://github.com/rene-dev/stmbl
this is the mistubishi encoder code: https://github.com/rene-dev/stmbl/blob/newstuff-v4/src/comps/encm.comp
currently we use smartserial as command via a mesa card, but we a also working on a ethernet version.
the idea is some udp based protocol like the mesa cards use, but that is still in development.
at the moment we are working to get version 4 of our hardware working, a lot of code needs to be done.
Loading Image...
Loading Image...
Loading Image...
some projects powered by stmbl:





Rene
Post by m***@hetnet.nl
I've been working on an ethernet controlled servo drive for some time now.
This drive uses RTNET and Xenomai-3.0.3 for the real-time communication.
The current control loop is on the drive, but the position control loop
is on the PC.
Currently only tree motor types are supported, being Mitsubishi MF-S13
Mitsubishi HC-PQ-[24]3 and the Osai DS-56. The Osai motor uses a
Hiperface encoder, so supporting another motor with Hiperface should be
a simple change of the encoder offset and number of poles.
Since the drives have to be synchronised to the PC it is important to
reduce the jitter to the drives. To do this I have made two modifications
to the uspace_xenomai interface. The first is that a posix timer is used
to generate the control frequency. The second is that the real-time
synchronisation function needs access to this timer. (Eventually this
has to be replaced by PTP)
Another change has to do with permissions, I'm not sure what the proper
fix is so there's a hack in there to do everything as root.
https://github.com/mark-v-d/motor_control.git
https://github.com/mark-v-d/linuxcnc.git
Please keep in mind this is all work in progress. The hardware needs
a few patches (notes in the schematic) and the software is nowhere near
complete. As soon as I've got everything working I'm going to make another
drive which works at 600V, and support at least the AEAT-6010/6012
and AEAT-9000-1GSH1 encoders.
regards,
Mark.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
Dmitry Yurtaev
2017-02-05 21:24:14 UTC
Permalink
Raw Message
hi!

very cool projects!

i played a bit with mitsubishi serial encoders, maybe i have some info
you may find useful.
i also collected info on some basic parameters of most mitsubishi
servo motors: like IDs, rated/max current and speed, number of poles
and few other constants in unknown units.
here's some of encoder requests/replies used by drives:

req=92 get encoder id
92 01 41 00 00 00 00 00 d2 - HC-KFS43 (41=OBA17)
92 01 41 83 00 00 00 00 51
92 01 44 d7 - HF-KP23 (44=OBA18)
req=1A type0/1 req
req=A2 type2/3 req
a2 11 b0 f4 07 79 ca 40 03 - HC-KFS43
a2 11 95 e4 05 e1 d5 40 b3 - HF-KP23
^^^^^^count^^^^^^
req=32 type4 req
req=7A motor type
7a 21 41 12 43 ff 00 a7 13 - HC-KFS43 (41, 12FF43)
7a 21 44 16 23 ff 00 a4 71 - HF-KP23 (44, 16FF23)

ping me if any of that seems interesting or you need testing with
different motor encoders (can check J4 HG-KR)

/dmitry
Post by Rene Hopf
Hi,
Interesting Project!
Im also working on a servo amp which supports hiperface, mitsubishi abs encoders, and many other protocols, and also resolvers.
https://github.com/rene-dev/stmbl
this is the mistubishi encoder code: https://github.com/rene-dev/stmbl/blob/newstuff-v4/src/comps/encm.comp
currently we use smartserial as command via a mesa card, but we a also working on a ethernet version.
the idea is some udp based protocol like the mesa cards use, but that is still in development.
at the moment we are working to get version 4 of our hardware working, a lot of code needs to be done.
https://www.dropbox.com/s/axa2u1sy6j62hp7/2016-12-13%2001.57.41.jpg?dl=0
https://www.dropbox.com/s/h2sby9pc4mfvdv8/2016-12-13%2001.57.27.jpg?dl=0
https://www.dropbox.com/s/citvmronmz9ryrt/2016-12-10%2021.12.50.jpg?dl=0
http://youtu.be/wXLcAZwjlzE
http://youtu.be/gwgnAeGjZrA
http://youtu.be/uMytcf41GPU
http://youtu.be/pMZQ4q7iM20
Rene
Post by m***@hetnet.nl
I've been working on an ethernet controlled servo drive for some time now.
This drive uses RTNET and Xenomai-3.0.3 for the real-time communication.
The current control loop is on the drive, but the position control loop
is on the PC.
Currently only tree motor types are supported, being Mitsubishi MF-S13
Mitsubishi HC-PQ-[24]3 and the Osai DS-56. The Osai motor uses a
Hiperface encoder, so supporting another motor with Hiperface should be
a simple change of the encoder offset and number of poles.
Since the drives have to be synchronised to the PC it is important to
reduce the jitter to the drives. To do this I have made two modifications
to the uspace_xenomai interface. The first is that a posix timer is used
to generate the control frequency. The second is that the real-time
synchronisation function needs access to this timer. (Eventually this
has to be replaced by PTP)
Another change has to do with permissions, I'm not sure what the proper
fix is so there's a hack in there to do everything as root.
https://github.com/mark-v-d/motor_control.git
https://github.com/mark-v-d/linuxcnc.git
Please keep in mind this is all work in progress. The hardware needs
a few patches (notes in the schematic) and the software is nowhere near
complete. As soon as I've got everything working I'm going to make another
drive which works at 600V, and support at least the AEAT-6010/6012
and AEAT-9000-1GSH1 encoders.
regards,
Mark.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
m***@hetnet.nl
2017-02-05 21:56:26 UTC
Permalink
Raw Message
Hi Dmitry,

Very nice, I suspected the motor type could be detected properly. You
just saved me a lot of time, because I was going to reverse engineer
the protocol... some day. Please mail me the info you have on these
encoders, so I can auto detect the motors properly. Right now if the
motor responds in half duplex I assume it's a MF-S13...

Mark.

Dmitry Yurtaev <***@gmail.com> wrote:

hi!

very cool projects!

i played a bit with mitsubishi serial encoders, maybe i have some info
you may find useful.
i also collected info on some basic parameters of most mitsubishi
servo motors: like IDs, rated/max current and speed, number of poles
and few other constants in unknown units.
here's some of encoder requests/replies used by drives:

req=92 get encoder id
92 01 41 00 00 00 00 00 d2 - HC-KFS43 (41=OBA17)
92 01 41 83 00 00 00 00 51
92 01 44 d7 - HF-KP23 (44=OBA18)
req=1A type0/1 req
req=A2 type2/3 req
a2 11 b0 f4 07 79 ca 40 03 - HC-KFS43
a2 11 95 e4 05 e1 d5 40 b3 - HF-KP23
^^^^^^count^^^^^^
req=32 type4 req
req=7A motor type
7a 21 41 12 43 ff 00 a7 13 - HC-KFS43 (41, 12FF43)
7a 21 44 16 23 ff 00 a4 71 - HF-KP23 (44, 16FF23)

ping me if any of that seems interesting or you need testing with
different motor encoders (can check J4 HG-KR)

/dmitry
Post by Rene Hopf
Hi,
Interesting Project!
Im also working on a servo amp which supports hiperface, mitsubishi abs encoders, and many other protocols, and also resolvers.
https://github.com/rene-dev/stmbl
this is the mistubishi encoder code: https://github.com/rene-dev/stmbl/blob/newstuff-v4/src/comps/encm.comp
currently we use smartserial as command via a mesa card, but we a also working on a ethernet version.
the idea is some udp based protocol like the mesa cards use, but that is still in development.
at the moment we are working to get version 4 of our hardware working, a lot of code needs to be done.
https://www.dropbox.com/s/axa2u1sy6j62hp7/2016-12-13%2001.57.41.jpg?dl=0
https://www.dropbox.com/s/h2sby9pc4mfvdv8/2016-12-13%2001.57.27.jpg?dl=0
https://www.dropbox.com/s/citvmronmz9ryrt/2016-12-10%2021.12.50.jpg?dl=0
http://youtu.be/wXLcAZwjlzE
http://youtu.be/gwgnAeGjZrA
http://youtu.be/uMytcf41GPU
http://youtu.be/pMZQ4q7iM20
Rene
Post by m***@hetnet.nl
I've been working on an ethernet controlled servo drive for some time now.
This drive uses RTNET and Xenomai-3.0.3 for the real-time communication.
The current control loop is on the drive, but the position control loop
is on the PC.
Currently only tree motor types are supported, being Mitsubishi MF-S13
Mitsubishi HC-PQ-[24]3 and the Osai DS-56. The Osai motor uses a
Hiperface encoder, so supporting another motor with Hiperface should be
a simple change of the encoder offset and number of poles.
Since the drives have to be synchronised to the PC it is important to
reduce the jitter to the drives. To do this I have made two modifications
to the uspace_xenomai interface. The first is that a posix timer is used
to generate the control frequency. The second is that the real-time
synchronisation function needs access to this timer. (Eventually this
has to be replaced by PTP)
Another change has to do with permissions, I'm not sure what the proper
fix is so there's a hack in there to do everything as root.
https://github.com/mark-v-d/motor_control.git
https://github.com/mark-v-d/linuxcnc.git
Please keep in mind this is all work in progress. The hardware needs
a few patches (notes in the schematic) and the software is nowhere near
complete. As soon as I've got everything working I'm going to make another
drive which works at 600V, and support at least the AEAT-6010/6012
and AEAT-9000-1GSH1 encoders.
regards,
Mark.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Dmitry Yurtaev
2017-02-05 22:17:25 UTC
Permalink
Raw Message
Mark,

yep, i will email you what i've got, just have to organize it a bit :)
afaik, HC-PQ, HC-MF and HC-MFS are the same motors with different encoders.
OBA17 encoders (HC-MFS) can do both: simplex or duplex.

/dmitry
Post by m***@hetnet.nl
Hi Dmitry,
Very nice, I suspected the motor type could be detected properly. You
just saved me a lot of time, because I was going to reverse engineer
the protocol... some day. Please mail me the info you have on these
encoders, so I can auto detect the motors properly. Right now if the
motor responds in half duplex I assume it's a MF-S13...
Mark.
hi!
very cool projects!
i played a bit with mitsubishi serial encoders, maybe i have some info
you may find useful.
i also collected info on some basic parameters of most mitsubishi
servo motors: like IDs, rated/max current and speed, number of poles
and few other constants in unknown units.
req=92 get encoder id
92 01 41 00 00 00 00 00 d2 - HC-KFS43 (41=OBA17)
92 01 41 83 00 00 00 00 51
92 01 44 d7 - HF-KP23 (44=OBA18)
req=1A type0/1 req
req=A2 type2/3 req
a2 11 b0 f4 07 79 ca 40 03 - HC-KFS43
a2 11 95 e4 05 e1 d5 40 b3 - HF-KP23
^^^^^^count^^^^^^
req=32 type4 req
req=7A motor type
7a 21 41 12 43 ff 00 a7 13 - HC-KFS43 (41, 12FF43)
7a 21 44 16 23 ff 00 a4 71 - HF-KP23 (44, 16FF23)
ping me if any of that seems interesting or you need testing with
different motor encoders (can check J4 HG-KR)
/dmitry
Post by Rene Hopf
Hi,
Interesting Project!
Im also working on a servo amp which supports hiperface, mitsubishi abs encoders, and many other protocols, and also resolvers.
https://github.com/rene-dev/stmbl
this is the mistubishi encoder code: https://github.com/rene-dev/stmbl/blob/newstuff-v4/src/comps/encm.comp
currently we use smartserial as command via a mesa card, but we a also working on a ethernet version.
the idea is some udp based protocol like the mesa cards use, but that is still in development.
at the moment we are working to get version 4 of our hardware working, a lot of code needs to be done.
https://www.dropbox.com/s/axa2u1sy6j62hp7/2016-12-13%2001.57.41.jpg?dl=0
https://www.dropbox.com/s/h2sby9pc4mfvdv8/2016-12-13%2001.57.27.jpg?dl=0
https://www.dropbox.com/s/citvmronmz9ryrt/2016-12-10%2021.12.50.jpg?dl=0
http://youtu.be/wXLcAZwjlzE
http://youtu.be/gwgnAeGjZrA
http://youtu.be/uMytcf41GPU
http://youtu.be/pMZQ4q7iM20
Rene
Post by m***@hetnet.nl
I've been working on an ethernet controlled servo drive for some time now.
This drive uses RTNET and Xenomai-3.0.3 for the real-time communication.
The current control loop is on the drive, but the position control loop
is on the PC.
Currently only tree motor types are supported, being Mitsubishi MF-S13
Mitsubishi HC-PQ-[24]3 and the Osai DS-56. The Osai motor uses a
Hiperface encoder, so supporting another motor with Hiperface should be
a simple change of the encoder offset and number of poles.
Since the drives have to be synchronised to the PC it is important to
reduce the jitter to the drives. To do this I have made two modifications
to the uspace_xenomai interface. The first is that a posix timer is used
to generate the control frequency. The second is that the real-time
synchronisation function needs access to this timer. (Eventually this
has to be replaced by PTP)
Another change has to do with permissions, I'm not sure what the proper
fix is so there's a hack in there to do everything as root.
https://github.com/mark-v-d/motor_control.git
https://github.com/mark-v-d/linuxcnc.git
Please keep in mind this is all work in progress. The hardware needs
a few patches (notes in the schematic) and the software is nowhere near
complete. As soon as I've got everything working I'm going to make another
drive which works at 600V, and support at least the AEAT-6010/6012
and AEAT-9000-1GSH1 encoders.
regards,
Mark.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
m***@hetnet.nl
2017-02-05 21:47:55 UTC
Permalink
Raw Message
Hello,

That's a pretty impressive bridge :-) I intend to use SiC FETs, mainly
because I want to use the drive as a power supply as well. With SiC FETs
the inductor become much smaller and cheaper.

Mark.

Rene Hopf <***@mac.com> wrote:

Hi,
Interesting Project!
Im also working on a servo amp which supports hiperface, mitsubishi abs encoders, and many other protocols, and also resolvers.
https://github.com/rene-dev/stmbl
this is the mistubishi encoder code: https://github.com/rene-dev/stmbl/blob/newstuff-v4/src/comps/encm.comp
currently we use smartserial as command via a mesa card, but we a also working on a ethernet version.
the idea is some udp based protocol like the mesa cards use, but that is still in development.
at the moment we are working to get version 4 of our hardware working, a lot of code needs to be done.
https://www.dropbox.com/s/axa2u1sy6j62hp7/2016-12-13%2001.57.41.jpg?dl=0
https://www.dropbox.com/s/h2sby9pc4mfvdv8/2016-12-13%2001.57.27.jpg?dl=0
https://www.dropbox.com/s/citvmronmz9ryrt/2016-12-10%2021.12.50.jpg?dl=0
some projects powered by stmbl:
http://youtu.be/wXLcAZwjlzE
http://youtu.be/gwgnAeGjZrA
http://youtu.be/uMytcf41GPU
http://youtu.be/pMZQ4q7iM20

Rene
Post by m***@hetnet.nl
I've been working on an ethernet controlled servo drive for some time now.
This drive uses RTNET and Xenomai-3.0.3 for the real-time communication.
The current control loop is on the drive, but the position control loop
is on the PC.
Currently only tree motor types are supported, being Mitsubishi MF-S13
Mitsubishi HC-PQ-[24]3 and the Osai DS-56. The Osai motor uses a
Hiperface encoder, so supporting another motor with Hiperface should be
a simple change of the encoder offset and number of poles.
Since the drives have to be synchronised to the PC it is important to
reduce the jitter to the drives. To do this I have made two modifications
to the uspace_xenomai interface. The first is that a posix timer is used
to generate the control frequency. The second is that the real-time
synchronisation function needs access to this timer. (Eventually this
has to be replaced by PTP)
Another change has to do with permissions, I'm not sure what the proper
fix is so there's a hack in there to do everything as root.
https://github.com/mark-v-d/motor_control.git
https://github.com/mark-v-d/linuxcnc.git
Please keep in mind this is all work in progress. The hardware needs
a few patches (notes in the schematic) and the software is nowhere near
complete. As soon as I've got everything working I'm going to make another
drive which works at 600V, and support at least the AEAT-6010/6012
and AEAT-9000-1GSH1 encoders.
regards,
Mark.
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Emc-developers mailing list
Emc-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
Nicklas Karlsson
2017-02-10 20:08:08 UTC
Permalink
Raw Message
Post by m***@hetnet.nl
I've been working on an ethernet controlled servo drive for some time now.
This drive uses RTNET and Xenomai-3.0.3 for the real-time communication.
The current control loop is on the drive, but the position control loop
is on the PC.
I also have ethernet servo drives.
Post by m***@hetnet.nl
...
Since the drives have to be synchronised to the PC it is important to
reduce the jitter to the drives.
Well actually not. A full period of jitter then using average time over 100 samples is 1% or about if not exact 1/n=(100/n)% of jitter. I have done this for stepper and have also written about how to do it with decimal point to reduce jitter then running servo loop at similar rate as stepper pulses.


What protocol do you use for Ethernet?


Regards Nicklas Karlsson
m***@hetnet.nl
2017-02-11 12:08:43 UTC
Permalink
Raw Message
Well actually not. A full period of jitter then using average
time over 100 samples is 1% or about if not exact 1/n=(100/n)%
of jitter.

The ethernet controller of the processor has a clock with a very
fine-grained control of the time. Currently this clock takes 3 seconds
to lock to the PC clock. Once locked it is very stable ... But there
is also the PWM frequency, which determines the sampling time of the
position and motor currents. I want all the drives to sample the position
at exactly the same time. For this I want to sample just before the next
data from the PC arrives. This way both the encoder data and the ethernet
packet arrive simultaneously and the current control loop has everything
up-to-date for the next computation. After the current control loop
has finished it sends the status back to the PC.

What using the timer brings, is that it allows me to compensate for the
delay from the sigwait to the actual sending of the packet. By
reading the timer with timer_gettime.

I have done this for stepper and have also written about how
to do it with decimal point to reduce jitter then running servo
loop at similar rate as stepper pulses.

What protocol do you use for Ethernet?

Currently it is an ad-hoc protocol over UDP. One port is used for
the timing and the PC broadcasts sync packets. I want to change this
protocol to PTP, but also use the hardware time-stamping of the ethernet
controller on the PC. Both will take some effort ad will have to come
after I've finished the mechanics. Currently there is no compensation
for propagation delay which causes one drive to sample slightly earlier
than the other, and swapping the ports on the switch causes the order
to change. The delay is well below 1us, so not an issue for mechanical
systems like milling machines and lathes.

Since the PTP protcol has to be mixed with the real-time control I need
to do something with scheduling. The TDMA driver included in RTNET is not
"suitable" because the UDP packets are tagged differently and the ethernet
controller in the microcontroller is not able to do all the checks. I
also use a switch, instead of a HUB which also makes the TDMA sub-optimal.
The drives have a 100Mb link and the PC had 1Gb.

The other port is the data for the control loop which is just a struct
sent with every UDP packet, and changed at will. If, for some reason,
I want to add a protocol I'll use another port.

regards,

Mark.
Nicklas Karlsson
2017-02-11 15:26:20 UTC
Permalink
Raw Message
Post by Nicklas Karlsson
Well actually not. A full period of jitter then using average
time over 100 samples is 1% or about if not exact 1/n=(100/n)%
of jitter.
The ethernet controller of the processor has a clock with a very
fine-grained control of the time. Currently this clock takes 3 seconds
to lock to the PC clock. Once locked it is very stable ... But there
is also the PWM frequency, which determines the sampling time of the
position and motor currents. I want all the drives to sample the position
at exactly the same time. For this I want to sample just before the next
data from the PC arrives. This way both the encoder data and the ethernet
packet arrive simultaneously and the current control loop has everything
up-to-date for the next computation. After the current control loop
has finished it sends the status back to the PC.
I make it a little bit different. PC and micro controller is running at slightly different clock so there is only a need to compensate for clock drift. I use micro controller internal clock and use arrival times to compensate for the clock drift.

The problem is I have no way to make PC send Ethernet packets with an accurate clock but with this method it is running smoothly anyway although with some extra delay.
Post by Nicklas Karlsson
What using the timer brings, is that it allows me to compensate for the
delay from the sigwait to the actual sending of the packet. By
reading the timer with timer_gettime.
My method compensate for all jitter in between clock used to trigger servo loop in PC to micro controller internal clock although with some extra delay.
Post by Nicklas Karlsson
I have done this for stepper and have also written about how
to do it with decimal point to reduce jitter then running servo
loop at similar rate as stepper pulses.
What protocol do you use for Ethernet?
I use a slightly modified Hostmot2 driver, stepper generators have been modified to send/receive positions encoder style in both directions. I am pretty sure messages are sent via UDP.

I am however thinking about CANopen messages over Ethernet, probably via UDP/IP since the dictionary and SDO communication would be very useful for parameters and it may be used to set parameters manually without following a standard for the entries, only the SDO messages.

The thing with the CANopen dictionary is it have an electronic datasheet so that a configuration tool could be used to access named parameters in the device. The name is in the dictionary while the micro controller only use numbers. Do anybody know about any similar protocol which may be used on Ethernet?
Post by Nicklas Karlsson
Currently it is an ad-hoc protocol over UDP. One port is used for
the timing and the PC broadcasts sync packets. I want to change this
protocol to PTP, but also use the hardware time-stamping of the ethernet
controller on the PC. Both will take some effort ad will have to come
after I've finished the mechanics. Currently there is no compensation
for propagation delay which causes one drive to sample slightly earlier
than the other, and swapping the ports on the switch causes the order
to change. The delay is well below 1us, so not an issue for mechanical
systems like milling machines and lathes.
Since the PTP protcol has to be mixed with the real-time control I need
to do something with scheduling. The TDMA driver included in RTNET is not
"suitable" because the UDP packets are tagged differently and the ethernet
controller in the microcontroller is not able to do all the checks. I
also use a switch, instead of a HUB which also makes the TDMA sub-optimal.
The drives have a 100Mb link and the PC had 1Gb.
As far as I understand PTP protocol is for very accurate clock synchronization?
Post by Nicklas Karlsson
The other port is the data for the control loop which is just a struct
sent with every UDP packet, and changed at will. If, for some reason,
I want to add a protocol I'll use another port.
Here I am thinking about CANopen. PDOs used for real time protocol is practically the same as sending a struct although byte order is defined, there are no padding and there exists standard communication profiles there the data is defined although it is usually possible to change by configuration. SDO and EDS electronic datasheet is however standardized so it is possible to access standardized or custom parameters in micro controller with a standard protocol.


Regards Nicklas Karlsson
m***@hetnet.nl
2017-02-11 16:42:54 UTC
Permalink
Raw Message
As far as I understand PTP protocol is for very accurate clock
synchronization?

Which is exactly what I want. Many microcontroller and network cards have
support for this, it's also called IEEE 1588. There even are switches
which re-timestamp so the jitter caused by the switch can be removed.
I can't give the numbers of what I have at the moment, but the goal is
to get the timing differences between the drives below 50ns. What I'm
using right now is just a quick and dirty method, so I can get the
hardware up and running and fix potential mistakes in the next version.

Here I am thinking about CANopen. PDOs used for real time protocol
is practically the same as sending a struct although byte order
is defined, there are no padding and there exists standard
communication profiles there the data is defined although it
is usually possible to change by configuration. SDO and EDS
electronic datasheet is however standardized so it is possible
to access standardized or custom parameters in micro controller
with a standard protocol.

CANopen sounds interesting. I'll have a look at it, a quick scan at
wikipedia also shows IEEE 1451. It would be really nice if a drive would
just present itself and all the variables would be available as pins.
Using existing and open protocols is definitely preferred.

regards,

Mark.
Nicklas Karlsson
2017-02-11 18:52:15 UTC
Permalink
Raw Message
Post by Nicklas Karlsson
As far as I understand PTP protocol is for very accurate clock synchronization?
Which is exactly what I want. Many microcontroller and network cards have
support for this, it's also called IEEE 1588. There even are switches
which re-timestamp so the jitter caused by the switch can be removed.
I can't give the numbers of what I have at the moment, but the goal is
to get the timing differences between the drives below 50ns. What I'm
using right now is just a quick and dirty method, so I can get the
hardware up and running and fix potential mistakes in the next version.
I thought within 1% or so was good enough and was happy with that. Within 50ns is really good, is it complicated to implement on micro controller?
Post by Nicklas Karlsson
Here I am thinking about CANopen. PDOs used for real time protocol
is practically the same as sending a struct although byte order
is defined, there are no padding and there exists standard
communication profiles there the data is defined although it
is usually possible to change by configuration. SDO and EDS
electronic datasheet is however standardized so it is possible
to access standardized or custom parameters in micro controller
with a standard protocol.
CANopen sounds interesting. I'll have a look at it, a quick scan at
wikipedia also shows IEEE 1451. It would be really nice if a drive would
just present itself and all the variables would be available as pins.
Not exactly but not to far away. Usually there is default configuration for PDOs which might be sent periodically and possible to map values list of available values in dictionary to PDOs.

There is a standard IDs used for PDO which usually is used for real time communication, these are usually simple messages with only the real time data where message format identified by the ID. There are also standard IDs for SDO messages used to access the dictionary. A electronic datasheet *.eds file may be generated for the device and interpreted by a configuration file.

Even though there a standards for which dictionary entries should be available configuration may access custom entries. Nice thing is configuration tool will probably work with only the dictionary entries actually needed implemented although other management functionality will not. There are also standard communication profiles for example for motors which will work more automatically.


I do not about other similar protocol. It should fulfill the requirements for linuxcnc rather well, possibility for real time data and a standard configuration tool.


Nicklas Karlsson
m***@hetnet.nl
2017-02-11 21:04:51 UTC
Permalink
Raw Message
I thought within 1% or so was good enough and was happy with
that. Within 50ns is really good, is it complicated to implement
on micro controller?

For machine control 1% is probably good enough. But I also have some
other uses with high speed (100MS/s) adc's in mind. These systems will
get a VCXO to adjust the frequency. This project is part of finding out
what kind of trouble I can expect to run into.

That being said, on the XMC4400 it's extremely simple to get proper
synchronisation. There is hardware to timestamp the incoming and outgoing
packets. There also is a clock which allows very fine grained frequency
adjustment. All built for PTP. If you have, for example, an Intel e1000e
ethernet card, this card also has the ability to timestamp the packets.

Once the PTP clocks are properly synchronised you just have to know when to
do what. The PTP clock on the XMC4400 can be used to generate an event
at that time.

This is the first microcontroller I've looked at with ethernet, but I
suspect many processors have these facilities.

Currently the sync packets consist of two timestamps. One is "now" on the
PC, and the other is the time of the next expiration of the posix timer.
An event is scheduled for this next expiration time. These events are used
to synchronise the PWM timer.

FWIW, you can have a look at the archive of the drive. In the udp_sync.cpp
file the sync packets are received. This is also where the synchronised
events are scheduled. These events are handled in ethernet.cpp which just
calls pwm.set_timestamp() for every event. The PWM synchronisation is a
bit more involved, because I also use dithering to adjust the frequency.

Because hardware timestamping is not used on the e1000e, "now" is
inaccurate, and a source of error. The other problem is that you have
to know the actual time of the posix timer expiration. I still have to
find out if I set an interval of 222222ns on a posix timer, it really is
222222ns and not some value rounded to the nearest possible interval.

regards,

Mark.

Nicklas Karlsson
2017-02-11 19:02:26 UTC
Permalink
Raw Message
Post by m***@hetnet.nl
CANopen sounds interesting. I'll have a look at it, a quick scan at
wikipedia also shows IEEE 1451. It would be really nice if a drive would
just present itself and all the variables would be available as pins.
Using existing and open protocols is definitely preferred.
I have looked at profibus but do not find a way to access custom parameters but I might be wrong. Profibus is however very useful for other reasons in linuxcnc since millions of these devices have manufctured for example like simple IO modules but also motor drivers which might be useful for CNC machining or at least to drive the spindle.
Loading...