Hi all,
I have used SOEM/Orocos master editing mySlave.h and mySlave.cpp
It is a really well done transparent master that use an unique taskcontext
for the master and automatically extend its functionalities using plugins
and RTT::services.
The master is working well, anyway I would like to have a TasKcontext with
a "slave activity" for every slave.
Having a Taskcontext for every slave would be usefull, for example in
order to have the possibility to load in each slave properties from an
.xml.
Anyway implementing such a structure I face a problem linked with the
facts:
-The master is the holder of a structure.
-The master use data contained in this structure to send them through
EtherCAT.
-Every slave have 2 structures/buffers that contain PDO mapped variables.
-These strucures can have different dimensions and have to be copied in a
specific field of the master structure to let it transmit datas.
The design problem that I have using a Task for every slave is:
1)Slave side:
Every kind of slave that I want to control with the master has a sort of
input_field and an output_field (like a std::bitset) containing PDO mapped
variables.
The size of these bitset can be different for every slave configuration
(PDO mapping) and the slave known the exact size of these structures after
its configurehook.
In my opinion every slave Task need al least 2 ports to communicate with
the superiors task and let them know its state, ecc.. and let them writing
for example it target.
Theese 2 ports will communicate the datas contained in the input_field and
output_field with the exterior environnement.
2)Master side:
I desire a transparent master that using the master-slave activities run
all the peers (slaves) like is explained in this usefull post:
http://www.orocos.org/forum/orocos/orocos-users/ann-fbsched-function-blo...
If it is transparent we don't need to change it depending on the connected
slaves.
The "only" thing that we have to do is let it know which slaves has to
control setting them as its peers using the deployer.
3)Communication between slave and Master:
While the communication with the exterior component has to be done using
ports I'm not sure of which is the best way to implement the communication
between master and slaves.
As I would run Master and slaves with master-slave activities there isn't a
problem of concurrency.
The question is "How mantain the Master transparency while I have to copy
input_field and output_field from the slave to the master structure?".
Basically the problem is that the master doesn't know the dimension of
theese fields till its configureHook() since they can vary depending on the
slaves.
Master structure is "autosizing" at the end of the configurehook so I
simply have to copy these fields in the appropriate field and repeating
this operation for every slave every updatehook of the master.
Possible solutions are:
A) Ports: use 2 ports even between Master and slaves.
The master can have only 2 ports connected with the 2 ports of all
slaves.
As the master thread executes the updatehook of the slaves one after
other I can read the information of the slave 1 from the master port after
the updatehook of slave 1 and then repeat it for every slave inside a loop
in the updatehook of the master.
Associated problems:
1) master doesn't know the dimension of the fields/buffers till its
configureHook.
2) defining ports with an autosizing data type like vector just move the
problem because would be difficult to put the information contained in the
buffer (that can be simple variables but of different dimensions[between 2
and 4 bytes]) in the vector.
B)Attributes: use 2 attributes for every slave containing the 2 "buffers".
In this way this fields can be displayed by the deployer in every moment
Associated problems:
1) Which type can I use to define an attribute? Can I define it with an
std::bitset, unsigned char buffer[10] or an home-made C++ class.
2) I should "modify" (with a cast) the vector containing taskcontext
pointer used in the above post to be able to read from
this kind of master the 2 compulsory attributes contained in every
slave.
C)Other solutions...other's design ideas
Thank you for any hint
B.R.
Luca & Leo
Design of an EtherCAT master using SOEM with a Taskcontext for e
On Thu, May 17, 2012 at 2:51 PM, Luca Magnabosco
<magnabosco [dot] luca [..] ...> wrote:
> Hi all,
> I have used SOEM/Orocos master editing mySlave.h and mySlave.cpp
> It is a really well done transparent master that use an unique taskcontext
> for the master and automatically extend its functionalities using plugins
> and RTT::services.
> The master is working well, anyway I would like to have a TasKcontext with a
> "slave activity" for every slave.
> Having a Taskcontext for every slave would be usefull, for example in order
> to have the possibility to load in each slave properties from an .xml.
It's far less effort to extend the marshalling plugin such that it
can marshall the properties of another service (a slave) of the same
component, instead of rewriting the soem bindings to Orocos.
>
> Anyway implementing such a structure I face a problem linked with the
> facts:
> -The master is the holder of a structure.
> -The master use data contained in this structure to send them through
> EtherCAT.
> -Every slave have 2 structures/buffers that contain PDO mapped variables.
> -These strucures can have different dimensions and have to be copied in a
> specific field of the master structure to let it transmit datas.
>
>
> The design problem that I have using a Task for every slave is:
>
> 1)Slave side:
> Every kind of slave that I want to control with the master has a sort of
> input_field and an output_field (like a std::bitset) containing PDO mapped
> variables.
> The size of these bitset can be different for every slave configuration (PDO
> mapping) and the slave known the exact size of these structures after its
> configurehook.
>
> In my opinion every slave Task need al least 2 ports to communicate with the
> superiors task and let them know its state, ecc.. and let them writing for
> example it target.
>
> Theese 2 ports will communicate the datas contained in the input_field and
> output_field with the exterior environnement.
>
> 2)Master side:
> I desire a transparent master that using the master-slave activities run all
> the peers (slaves) like is explained in this usefull post:
> http://www.orocos.org/forum/orocos/orocos-users/ann-fbsched-function-blo...
> If it is transparent we don't need to change it depending on the connected
> slaves.
> The "only" thing that we have to do is let it know which slaves has to
> control setting them as its peers using the deployer.
>
> 3)Communication between slave and Master:
> While the communication with the exterior component has to be done using
> ports I'm not sure of which is the best way to implement the communication
> between master and slaves.
>
> As I would run Master and slaves with master-slave activities there isn't a
> problem of concurrency.
> The question is "How mantain the Master transparency while I have to copy
> input_field and output_field from the slave to the master structure?".
> Basically the problem is that the master doesn't know the dimension of
> theese fields till its configureHook() since they can vary depending on the
> slaves.
> Master structure is "autosizing" at the end of the configurehook so I simply
> have to copy these fields in the appropriate field and repeating this
> operation for every slave every updatehook of the master.
>
>
> Possible solutions are:
>
> A) Ports: use 2 ports even between Master and slaves.
> The master can have only 2 ports connected with the 2 ports of all
> slaves.
> As the master thread executes the updatehook of the slaves one after
> other I can read the information of the slave 1 from the master port after
> the updatehook of slave 1 and then repeat it for every slave inside a loop
> in the updatehook of the master.
> Associated problems:
> 1) master doesn't know the dimension of the fields/buffers till its
> configureHook.
> 2) defining ports with an autosizing data type like vector just move the
> problem because would be difficult to put the information contained in the
> buffer (that can be simple variables but of different dimensions[between 2
> and 4 bytes]) in the vector.
>
>
> B)Attributes: use 2 attributes for every slave containing the 2 "buffers".
> In this way this fields can be displayed by the deployer in every moment
> Associated problems:
> 1) Which type can I use to define an attribute? Can I define it with an
> std::bitset, unsigned char buffer[10] or an home-made C++ class.
> 2) I should "modify" (with a cast) the vector containing taskcontext pointer
> used in the above post to be able to read from
> this kind of master the 2 compulsory attributes contained in every
> slave.
>
> C)Other solutions...other's design ideas
I can't believe you're trying/considering this. The design of the SOEM
master using services for slaves was not by accident and should not be
changed. I think you'll find little or no support for taking out
slaves into components.
I suggest that you suggest what's wrong with the current
infrastructure which limits your use of services as slaves within the
SOEM master.
Peter
Design of an EtherCAT master using SOEM with a Taskcontext for e
A Divendres, 18 de maig de 2012, Peter Soetens va escriure:
> On Thu, May 17, 2012 at 2:51 PM, Luca Magnabosco
>
> <magnabosco [dot] luca [..] ...> wrote:
> > Hi all,
> > I have used SOEM/Orocos master editing mySlave.h and mySlave.cpp
> > It is a really well done transparent master that use an unique
> > taskcontext for the master and automatically extend its functionalities
> > using plugins and RTT::services.
> > The master is working well, anyway I would like to have a TasKcontext
> > with a "slave activity" for every slave.
> > Having a Taskcontext for every slave would be usefull, for example in
> > order to have the possibility to load in each slave properties from an
> > .xml.
>
> It's far less effort to extend the marshalling plugin such that it
> can marshall the properties of another service (a slave) of the same
> component, instead of rewriting the soem bindings to Orocos.
well, depends. Understand soem bindings to Orocos is not quite easy. Luca have
done a good job studing your code. Actually, orocos-soem works with your soem
patch version, that in our case doesn't work. If not, you have to change some
cmake and manifest files.
Also, for an student as Luca that has to do his master thesis, adapt soem-
orocos code is more easy that extend the marshalling plugin, using the orocos
sources (AFAIK).
In our case we have to add that soem-orocos implementation has a problem with
our drive, because to create the slaves you read the name property of the
device and using a map, create the slave object. Our drive has this field
empty. So, we should have to make some modification.
>
> > Anyway implementing such a structure I face a problem linked with the
> > facts:
> > -The master is the holder of a structure.
> > -The master use data contained in this structure to send them through
> > EtherCAT.
> > -Every slave have 2 structures/buffers that contain PDO mapped variables.
> > -These strucures can have different dimensions and have to be copied in a
> > specific field of the master structure to let it transmit datas.
> >
> >
> > The design problem that I have using a Task for every slave is:
> >
> > 1)Slave side:
> > Every kind of slave that I want to control with the master has a sort of
> > input_field and an output_field (like a std::bitset) containing PDO
> > mapped variables.
> > The size of these bitset can be different for every slave configuration
> > (PDO mapping) and the slave known the exact size of these structures
> > after its configurehook.
> >
> > In my opinion every slave Task need al least 2 ports to communicate with
> > the superiors task and let them know its state, ecc.. and let them
> > writing for example it target.
> >
> > Theese 2 ports will communicate the datas contained in the input_field
> > and output_field with the exterior environnement.
> >
> > 2)Master side:
> > I desire a transparent master that using the master-slave activities run
> > all the peers (slaves) like is explained in this usefull post:
> > http://www.orocos.org/forum/orocos/orocos-users/ann-fbsched-function-bloc
> > k-scheduling-component If it is transparent we don't need to change it
> > depending on the connected slaves.
> > The "only" thing that we have to do is let it know which slaves has to
> > control setting them as its peers using the deployer.
> >
> > 3)Communication between slave and Master:
> > While the communication with the exterior component has to be done using
> > ports I'm not sure of which is the best way to implement the
> > communication between master and slaves.
> >
> > As I would run Master and slaves with master-slave activities there isn't
> > a problem of concurrency.
> > The question is "How mantain the Master transparency while I have to copy
> > input_field and output_field from the slave to the master structure?".
> > Basically the problem is that the master doesn't know the dimension of
> > theese fields till its configureHook() since they can vary depending on
> > the slaves.
> > Master structure is "autosizing" at the end of the configurehook so I
> > simply have to copy these fields in the appropriate field and repeating
> > this operation for every slave every updatehook of the master.
> >
> >
> > Possible solutions are:
> >
> > A) Ports: use 2 ports even between Master and slaves.
> > The master can have only 2 ports connected with the 2 ports of all
> > slaves.
> > As the master thread executes the updatehook of the slaves one after
> > other I can read the information of the slave 1 from the master port
> > after the updatehook of slave 1 and then repeat it for every slave
> > inside a loop in the updatehook of the master.
> > Associated problems:
> > 1) master doesn't know the dimension of the fields/buffers till its
> > configureHook.
> > 2) defining ports with an autosizing data type like vector just move the
> > problem because would be difficult to put the information contained in
> > the buffer (that can be simple variables but of different
> > dimensions[between 2 and 4 bytes]) in the vector.
> >
> >
> > B)Attributes: use 2 attributes for every slave containing the 2
> > "buffers". In this way this fields can be displayed by the deployer in
> > every moment Associated problems:
> > 1) Which type can I use to define an attribute? Can I define it with an
> > std::bitset, unsigned char buffer[10] or an home-made C++ class.
> > 2) I should "modify" (with a cast) the vector containing taskcontext
> > pointer used in the above post to be able to read from
> > this kind of master the 2 compulsory attributes contained in every
> > slave.
> >
> > C)Other solutions...other's design ideas
>
> I can't believe you're trying/considering this. The design of the SOEM
> master using services for slaves was not by accident and should not be
> changed. I think you'll find little or no support for taking out
> slaves into components.
Peter, the soem-orocos binding is a very good piece of software. I (and Luca
agree with me) think that the soem-orocos has a very good design. Another
question is if it fits our needs!!
> I suggest that you suggest what's wrong with the current
> infrastructure which limits your use of services as slaves within the
> SOEM master.
- As I have commented before, the current design doesn't work (we think) with
our device. So, the SoemDriverFactory::createDriver(ec_slavet* mem_loc)
FactoryMap::const_iterator it = m_factory_map.find(std::string(
mem_loc->name));
never will works for us, because this field is empty in our drive.
- We cannot load properties for the slaves.
- I personally don't understand why didn't you apply the relation of:
- master --> component
- slave1 --> component1
- slave2 --> component2
.....
for example, we could have one master and several different components that
needs special settings in the begin.
- The access to the input /output part of the bus is done by a assignation.
I'm not very confortable with this part of soem. I think that it's a bit
fragile, and some kind of functions should be used to acces to the data sent.
Some kind of function to acces to the ec_slave struct should be necessary
IMHO.
We don't have problems because just _only_ one process acces to the data in
main loop, but if some component is the master, _only_ this component should
access to the bus.
But maybe I'm wrong, I wouldn't want to have a extremist position in this.
Please, could you explain why this design?
Thanks for all,
Leo
Design of an EtherCAT master using SOEM with a Taskcontext for e
On Sun, May 20, 2012 at 1:03 AM, Leopold Palomo-Avellaneda <
leopold [dot] palomo [..] ...> wrote:
> A Divendres, 18 de maig de 2012, Peter Soetens va escriure:
> > On Thu, May 17, 2012 at 2:51 PM, Luca Magnabosco
> >
> > <magnabosco [dot] luca [..] ...> wrote:
> > > Hi all,
> > > I have used SOEM/Orocos master editing mySlave.h and mySlave.cpp
> > > It is a really well done transparent master that use an unique
> > > taskcontext for the master and automatically extend its functionalities
> > > using plugins and RTT::services.
> > > The master is working well, anyway I would like to have a TasKcontext
> > > with a "slave activity" for every slave.
> > > Having a Taskcontext for every slave would be usefull, for example in
> > > order to have the possibility to load in each slave properties from an
> > > .xml.
> >
> > It's far less effort to extend the marshalling plugin such that it
> > can marshall the properties of another service (a slave) of the same
> > component, instead of rewriting the soem bindings to Orocos.
>
> well, depends. Understand soem bindings to Orocos is not quite easy. Luca
> have
> done a good job studing your code. Actually, orocos-soem works with your
> soem
> patch version, that in our case doesn't work. If not, you have to change
> some
> cmake and manifest files.
>
> Also, for an student as Luca that has to do his master thesis, adapt soem-
> orocos code is more easy that extend the marshalling plugin, using the
> orocos
> sources (AFAIK).
>
> In our case we have to add that soem-orocos implementation has a problem
> with
> our drive, because to create the slaves you read the name property of the
> device and using a map, create the slave object. Our drive has this field
> empty. So, we should have to make some modification.
>
> >
> > > Anyway implementing such a structure I face a problem linked with the
> > > facts:
> > > -The master is the holder of a structure.
> > > -The master use data contained in this structure to send them through
> > > EtherCAT.
> > > -Every slave have 2 structures/buffers that contain PDO mapped
> variables.
> > > -These strucures can have different dimensions and have to be copied
> in a
> > > specific field of the master structure to let it transmit datas.
> > >
> > >
> > > The design problem that I have using a Task for every slave is:
> > >
> > > 1)Slave side:
> > > Every kind of slave that I want to control with the master has a sort
> of
> > > input_field and an output_field (like a std::bitset) containing PDO
> > > mapped variables.
> > > The size of these bitset can be different for every slave configuration
> > > (PDO mapping) and the slave known the exact size of these structures
> > > after its configurehook.
> > >
> > > In my opinion every slave Task need al least 2 ports to communicate
> with
> > > the superiors task and let them know its state, ecc.. and let them
> > > writing for example it target.
> > >
> > > Theese 2 ports will communicate the datas contained in the input_field
> > > and output_field with the exterior environnement.
> > >
> > > 2)Master side:
> > > I desire a transparent master that using the master-slave activities
> run
> > > all the peers (slaves) like is explained in this usefull post:
> > >
> http://www.orocos.org/forum/orocos/orocos-users/ann-fbsched-function-bloc
> > > k-scheduling-component If it is transparent we don't need to change it
> > > depending on the connected slaves.
> > > The "only" thing that we have to do is let it know which slaves has to
> > > control setting them as its peers using the deployer.
> > >
> > > 3)Communication between slave and Master:
> > > While the communication with the exterior component has to be done
> using
> > > ports I'm not sure of which is the best way to implement the
> > > communication between master and slaves.
> > >
> > > As I would run Master and slaves with master-slave activities there
> isn't
> > > a problem of concurrency.
> > > The question is "How mantain the Master transparency while I have to
> copy
> > > input_field and output_field from the slave to the master
> structure?".
> > > Basically the problem is that the master doesn't know the dimension of
> > > theese fields till its configureHook() since they can vary depending on
> > > the slaves.
> > > Master structure is "autosizing" at the end of the configurehook so I
> > > simply have to copy these fields in the appropriate field and repeating
> > > this operation for every slave every updatehook of the master.
> > >
> > >
> > > Possible solutions are:
> > >
> > > A) Ports: use 2 ports even between Master and slaves.
> > > The master can have only 2 ports connected with the 2 ports of all
> > > slaves.
> > > As the master thread executes the updatehook of the slaves one
> after
> > > other I can read the information of the slave 1 from the master port
> > > after the updatehook of slave 1 and then repeat it for every slave
> > > inside a loop in the updatehook of the master.
> > > Associated problems:
> > > 1) master doesn't know the dimension of the fields/buffers till its
> > > configureHook.
> > > 2) defining ports with an autosizing data type like vector just move
> the
> > > problem because would be difficult to put the information contained in
> > > the buffer (that can be simple variables but of different
> > > dimensions[between 2 and 4 bytes]) in the vector.
> > >
> > >
> > > B)Attributes: use 2 attributes for every slave containing the 2
> > > "buffers". In this way this fields can be displayed by the deployer in
> > > every moment Associated problems:
> > > 1) Which type can I use to define an attribute? Can I define it with an
> > > std::bitset, unsigned char buffer[10] or an home-made C++ class.
> > > 2) I should "modify" (with a cast) the vector containing taskcontext
> > > pointer used in the above post to be able to read from
> > > this kind of master the 2 compulsory attributes contained in every
> > > slave.
> > >
> > > C)Other solutions...other's design ideas
> >
> > I can't believe you're trying/considering this. The design of the SOEM
> > master using services for slaves was not by accident and should not be
> > changed. I think you'll find little or no support for taking out
> > slaves into components.
>
> Peter, the soem-orocos binding is a very good piece of software. I (and
> Luca
> agree with me) think that the soem-orocos has a very good design. Another
> question is if it fits our needs!!
>
> > I suggest that you suggest what's wrong with the current
> > infrastructure which limits your use of services as slaves within the
> > SOEM master.
>
> - As I have commented before, the current design doesn't work (we think)
> with
> our device. So, the SoemDriverFactory::createDriver(ec_slavet* mem_loc)
>
> FactoryMap::const_iterator it = m_factory_map.find(std::string(
> mem_loc->name));
>
> never will works for us, because this field is empty in our drive.
>
I understand. So we need to implement an alternative factory map which
contains a more reliable ID than the 'name' string.
>
>
> - We cannot load properties for the slaves.
>
This is not true. The piece of C++ code you need to write to load
properties into a slave is a one-liner. It's not in the operation
interface, but it could be easily added, and it would be useful to other
projects as well.
>
> - I personally don't understand why didn't you apply the relation of:
> - master --> component
> - slave1 --> component1
> - slave2 --> component2
> .....
>
>
> for example, we could have one master and several different components that
> needs special settings in the begin.
>
Basically, Service = component - execution engine; ie component - 'thread'
- 'hooks'
Since slaves never have an own thread (only the master has), we only gave
up the part we did not need.
> - The access to the input /output part of the bus is done by a assignation.
> I'm not very confortable with this part of soem. I think that it's a bit
> fragile, and some kind of functions should be used to acces to the data
> sent.
> Some kind of function to acces to the ec_slave struct should be necessary
> IMHO.
>
I can imagine, so this is an improvement to soem.
>
> We don't have problems because just _only_ one process acces to the data in
> main loop, but if some component is the master, _only_ this component
> should
> access to the bus.
>
> But maybe I'm wrong, I wouldn't want to have a extremist position in this.
> Please, could you explain why this design?
>
Services are 'light' components. Even more, if your service would require a
start/stop hook, you are free to add this yourself, without the overhead of
the default hooks in every RTT component. Services are the policy-free
classes of RTT (does not impose any behavior) but offer all mechanisms, so
anything is implementable with a service, at the cost of writing more
boilerplate code yourself.
Now, some supportive parts of RTT or OCL have not yet been 'upgraded' to
also work on (nested) services (RTT 1.x legacy), but this is often trivial
to add yourself, or complain about on the mailing list for a fix.
Peter
Design of an EtherCAT master using SOEM with a Taskcontext for e
Hi Ruben,
>Are the VendorID and ProductID filled in? I think it would make more
>sense to also support the creation of slaves using this information.
>It would not be hard at all to add this.
Of course it can be a good solution, these fields are filled in in our
case, and they seem to be compulsory for every Ethercat slave.
>> For example: we can be interested in have a different PDO mapping,
>This is perfectly possible with the current master. I use it myself too.
I'm not sure to have understand how you use SDO to set the PDO mapping
before the command "ec_config_map(&m_IOmap)".
Even if the "!driver->configure()" command would be placed before the
creation of the IOmap you could call the configure of every "kind of slave"
but not the configure of every slave. What I mean is that only one PDO
mapping can be set , for all the slaves that have the same name, at the
moment. Isn't it?
>> a
>> different operation-mode (the motor can be controlled sending speeds or
>> positions, or torques) and
>This is also possible, you can easily to some SDO_writes in the
>configure function of the slave.
It's true. As you have written a specific salve can be modified using
SDO_writes. But if the SDO you want to do has a different value (Es:
different op mode), between slaves having the same name, you have to do
that, adding a specific function to the interface of the slave service,
(and call it for the specific slave-service) because if the SDO is done in
the configure of the slave it would be the same for every slave having the
same name.
Concluding, as you have already written, the main trick would be
have different start(), update() and stop().
Two above problems are linked with this approach.
Maybe I'm not considering the problem from the right point of view? .. my
basic idea would be to have the possibility to configure every slave one by
one to grant all possible configurations.
Best regards
Luca
Design of an EtherCAT master using SOEM with a Taskcontext for e
On Wed, May 30, 2012 at 1:07 AM, Luca Magnabosco
<magnabosco [dot] luca [..] ...> wrote:
> Hi Ruben,
>
>>Are the VendorID and ProductID filled in? I think it would make more
>>sense to also support the creation of slaves using this information.
>>It would not be hard at all to add this.
>
> Of course it can be a good solution, these fields are filled in in our case,
> and they seem to be compulsory for every Ethercat slave.
>
>>> For example: we can be interested in have a different PDO mapping,
>>This is perfectly possible with the current master. I use it myself too.
>
> I'm not sure to have understand how you use SDO to set the PDO mapping
> before the command "ec_config_map(&m_IOmap)".
I think you are not on the latest version of the master branch of the
soem stack. I changed the soem_master_component a little bit to call
ec_config_map after the configuration of the drivers. This makes it
possible to change the PDO mapping during the configuration of the
slaves.
> Even if the "!driver->configure()" command would be placed before the
> creation of the IOmap you could call the configure of every "kind of slave"
> but not the configure of every slave. What I mean is that only one PDO
> mapping can be set , for all the slaves that have the same name, at the
> moment. Isn't it?
No, it is possible! But it is also not trivial to do ATM ;). What you
really need is to get to property values during the driver->configure,
if this is possible you can change PDO mappings easily using a
property during the configuration of your driver.
>
>>> a
>>> different operation-mode (the motor can be controlled sending speeds or
>>> positions, or torques) and
>
>>This is also possible, you can easily to some SDO_writes in the
>>configure function of the slave.
>
> It's true. As you have written a specific salve can be modified using
> SDO_writes. But if the SDO you want to do has a different value (Es:
> different op mode), between slaves having the same name, you have to do
> that, adding a specific function to the interface of the slave service, (and
> call it for the specific slave-service) because if the SDO is done in the
> configure of the slave it would be the same for every slave having the same
> name.
> Concluding, as you have already written, the main trick would be
> have different start(), update() and stop().
> Two above problems are linked with this approach.
> Maybe I'm not considering the problem from the right point of view? .. my
> basic idea would be to have the possibility to configure every slave one by
> one to grant all possible configurations.
So what we need to add to the soem_driver is a way to read out
property values during the configuration of the slave, once that is
possible you can use the soem stack as it is? I do not see why you
would need different start() update() stop() functions?
> Best regards
>
> Luca
>
Ruben
Design of an EtherCAT master using SOEM with a Taskcontext for e
Hi Ruben,
sorry for answering so late.
>I think you are not on the latest version of the master branch of the
>soem stack. I changed the soem_master_component a little bit to call
>ec_config_map after the configuration of the drivers. This makes it
>possible to change the PDO mapping during the configuration of the
>slaves.
I had understood, anyway I had already solved this problem.
>No, it is possible! But it is also not trivial to do ATM ;). What you
>really need is to get to property values during the driver->configure,
>if this is possible you can change PDO mappings easily using a
>property during the configuration of your driver.
So you are saying that each instance of driver could call a different
configuration file
depending on "something" that is different even between the slaves having
the same name,
for example?
>So what we need to add to the soem_driver is a way to read out
>property values during the configuration of the slave, once that is
>possible you can use the soem stack as it is? I do not see why you
>would need different start() update() stop() functions?
First of all as I have already said, in my opinion, SOEM/Orocos master as
it is really well done.
My different approach is caused by the slaves I have and by the fact that I
would like to use every slave
in an independent way even if they have the same name.
Going on with Orocos and Soem I'm thinking that:
1)Properties can be usefully load for every slave (not only for every group
of slaves having the same name)
to set parameters like (In my case) maximum speed,maximum torque...
2)For different PDO mappings I think that they should be hard coded (for
each PDO mapping you want to use with your slave*) just because
a different PDO mapping cause different variables (PDO mapping object)
to be accepted by the slave and so you need at least a different
updateHook().
A different PDO mapping affect data retreived from
ec_slave[i].inputs/outputs. For example the first variable of a PDO mapping
can be of 16 bytes while the first of another just 8 or 32. So it should be
a problem for the slave's updatehook to send outside by ports these
informations without make the updatehook depending from the PDO mapping.
For these reason I was writing about different start(), stop(),update()
even if the problem can be reduced thinking only in different updatehook().
*I mean: -Pdo mapping number one -> a class slavename1 with its proper
updatehook()
-Pdo mapping number two -> a class slavename2 with its
proper updatehook()
If these "problems" can be solved with the existing master it would be the
favourite solution.
I'm interested in using DC clock too, but it can be easily solved making
the activity master aperiodic and triggering for it depending on the drift
between ec_send/receive of the master and sync0 of the slave. It would be
something similar to ebox.c.
Best regards
Luca
Design of an EtherCAT master using SOEM with a Taskcontext for e
On Thu, Jun 7, 2012 at 3:19 PM, Luca Magnabosco
<magnabosco [dot] luca [..] ...>wrote:
> Hi Ruben,
>
> sorry for answering so late.
>
> >I think you are not on the latest version of the master branch of the
> >soem stack. I changed the soem_master_component a little bit to call
> >ec_config_map after the configuration of the drivers. This makes it
> >possible to change the PDO mapping during the configuration of the
> >slaves.
>
> I had understood, anyway I had already solved this problem.
>
>
> >No, it is possible! But it is also not trivial to do ATM ;). What you
> >really need is to get to property values during the driver->configure,
> >if this is possible you can change PDO mappings easily using a
> >property during the configuration of your driver.
>
> So you are saying that each instance of driver could call a different
> configuration file
> depending on "something" that is different even between the slaves having
> the same name,
> for example?
>
We could extend the master component API such that you can replace the
'driver' for slave number 'X'. This would also allow different
implementations, even if the slaves are identical.
>
>
> >So what we need to add to the soem_driver is a way to read out
> >property values during the configuration of the slave, once that is
> >possible you can use the soem stack as it is? I do not see why you
> >would need different start() update() stop() functions?
>
> First of all as I have already said, in my opinion, SOEM/Orocos master as
> it is really well done.
> My different approach is caused by the slaves I have and by the fact that
> I would like to use every slave
> in an independent way even if they have the same name.
> Going on with Orocos and Soem I'm thinking that:
>
> 1)Properties can be usefully load for every slave (not only for every
> group of slaves having the same name)
> to set parameters like (In my case) maximum speed,maximum torque...
>
> 2)For different PDO mappings I think that they should be hard coded (for
> each PDO mapping you want to use with your slave*) just because
> a different PDO mapping cause different variables (PDO mapping object)
> to be accepted by the slave and so you need at least a different
> updateHook().
> A different PDO mapping affect data retreived from
> ec_slave[i].inputs/outputs. For example the first variable of a PDO mapping
> can be of 16 bytes while the first of another just 8 or 32. So it should be
> a problem for the slave's updatehook to send outside by ports these
> informations without make the updatehook depending from the PDO mapping.
>
This is too technical for me to understand. Maybe Ruben can cast some light
on this....
> For these reason I was writing about different start(), stop(),update()
> even if the problem can be reduced thinking only in different updatehook().
>
> *I mean: -Pdo mapping number one -> a class slavename1 with its proper
> updatehook()
> -Pdo mapping number two -> a class slavename2 with its
> proper updatehook()
>
> If these "problems" can be solved with the existing master it would be the
> favourite solution.
>
> I'm interested in using DC clock too, but it can be easily solved making
> the activity master aperiodic and triggering for it depending on the drift
> between ec_send/receive of the master and sync0 of the slave. It would be
> something similar to ebox.c.
>
>
> Best regards
>
> Luca
>
What I understood until now is that you're missing a mechanism to have very
specific driver implementations for a specific slave and specific
properties for that slave. Independent of the 'name' or a common driver
being available.
Peter
Design of an EtherCAT master using SOEM with a Taskcontext for e
First of all, as Leo said, me too I think soem-orocos binding is a very
good piece of software.
I was leading to imagine a different structure because of our needs.
> I suggest that you suggest what's wrong with the current infrastructure
> which limits your use of services as slaves within
> the SOEM master.
Using our slave became clear that:
1) As the table that SOEM/Orocos Master use to create a service for every
slave is based on names from ec_slave[i].name, if this field is not well
filled, the correspondent driver service will not be created.
As this field* depends from the name written in the EPROM of the slave, if
the name is not written, the field will be written with a "constructed
name" and this constructed name, at the moment, can't be the name of a C++
class.
2)We are using ethercat slaves to control servo-motors. We can be
interested in have different settings for every slave, even if the slaves
have the same type (same name).
For example: we can be interested in have a different PDO mapping, a
different operation-mode (the motor can be controlled sending speeds or
positions, or torques) and consequently a different start(), update() and
stop().
3)Our slaves required a PDO command to switch off correctly before setting
the state of the ethercat state-machine to a state "lower" than Operational
so, in my opinion a stophook as to be added that call stop() of the slaves
and then send PDO wit ec_send_processdata()
* [written during ec_config(), described in the line 405 of
ethercatconfig.c using ec_siifind(..) described in ethercatmain.c]
Best regards
Luca
Design of an EtherCAT master using SOEM with a Taskcontext for e
Hello Luca, Leopold,
On Sun, May 20, 2012 at 3:58 PM, Luca Magnabosco
<magnabosco [dot] luca [..] ...> wrote:
> First of all, as Leo said, me too I think soem-orocos binding is a very good
> piece of software.
> I was leading to imagine a different structure because of our needs.
>
>> I suggest that you suggest what's wrong with the current infrastructure
>> which limits your use of services as slaves within
>> the SOEM master.
>
> Using our slave became clear that:
> 1) As the table that SOEM/Orocos Master use to create a service for every
> slave is based on names from ec_slave[i].name, if this field is not well
> filled, the correspondent driver service will not be created.
Are the VendorID and ProductID filled in? I think it would make more
sense to also support the creation of slaves using this information.
It would not be hard at all to add this.
> As this field* depends from the name written in the EPROM of the slave, if
> the name is not written, the field will be written with a "constructed name"
> and this constructed name, at the moment, can't be the name of a C++ class.
>
>
> 2)We are using ethercat slaves to control servo-motors. We can be interested
> in have different settings for every slave, even if the slaves have the same
> type (same name).
> For example: we can be interested in have a different PDO mapping,
This is perfectly possible with the current master. I use it myself too.
> a
> different operation-mode (the motor can be controlled sending speeds or
> positions, or torques) and
This is also possible, you can easily to some SDO_writes in the
configure function of the slave.
> consequently a different start(), update() and
> stop().
This would be a little trickier to do. I have no idea at the moment
how we could select a different driver implementation for different
slaves of the same type.
> 3)Our slaves required a PDO command to switch off correctly before setting
> the state of the ethercat state-machine to a state "lower" than Operational
> so, in my opinion a stophook as to be added that call stop() of the slaves
> and then send PDO wit ec_send_processdata()
>
You can easily add more operations to slave drivers.
>
> * [written during ec_config(), described in the line 405 of ethercatconfig.c
> using ec_siifind(..) described in ethercatmain.c]
>
> Best regards
> Luca
>
Best regards,
Ruben
>
>
> --
> Orocos-Users mailing list
> Orocos-Users [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-users
>