[etherlab-users] Using EK1100 & EL2008 with DC
Oguz Dilmac
odilmac at bilko.com.tr
Wed Jul 18 11:32:01 CEST 2012
Hi,
I found a bug in my configuration functions. Thats why I can't use
EL2008 when I re-run the configuration for the second time.
But I found that if I use DC, it takes too much time (more than 5000ms)
for master to change state to OP state.
I'll create another topic for it.
Best regards,
Oguz.
06.07.2012 11:59 tarihinde, Oguz Dilmac yazd?:
>
> 06.07.2012 09:51 tarihinde, Ralf Roesch yazd?:
>> On Thu Jul 05 2012 17:33:47 GMT+0200 (CEST), Oguz Dilmac
>> <odilmac at bilko.com.tr> wrote:
>>> Now I have another problems:
>>>
>>> 1. If I don't use DC, I can control the drive and IO devices at the
>>> same time.
>> o.k, which action do you perform in your control cycle?
>
> I can use "homing" and "profile position" without a problem. I can
> rotate the motor to whereever I like.
> If I use "Interpolated Position" or "Cyclic synchronous position" I
> can hear "knock" sounds from the motor. I see that, my drive doesn't
> support SM synchronisation.
>
> I need to use those two modes. Therefore I need to use DC synchronisation.
> If I configure DC with "ecrt_slave_config_dc", and if I dont have any
> other slave, I can control the drive in "Cyclic synchronous position"
> mode without a problem.
>
>>> 2. If I use DC (without configuring IO devices), I can't go to
>>> operational at first initialisation. But If I re-run the config
>>> sequence I can control the drive.
>> Which devices, drives do you use?
>> How do you bring up the devices in operational state?
>> What is done in your configuration sequence?
>
> I have:
> One ServoOne junior servo motor driver and it's motor. A demo case
> from LT-I
> One EK1100 for the bus master
> One EL2008 Output module from Beckhoff
> One EL1008 Input module from Beckhoff
>
> I use pretty much the examples for PDO configuration and domain
> assignments.
> I implement the program as a kernel module.
> I have one periodic RT task and several non periodic RT tasks.
> I also use one standart linux kernel task for ethercat master start,
> stop, SDO download upload functions. Thanks to Graeme.
> Here is a pseudo code of what I do. I'm writing the one domain
> version. Two domain is almost the same:
>
> In the Init module section:
> {
> ...
> Ethercat_init
> {
> rt_sem_init(master_sem)
> master = ecrt_request_master(0)
> ecrt_master_callbacks
> domain = ecrt_master_create_domain(master)
> domain_pd = ecrt_domain_data(domain)
> }
> ...
>
> create linux kernel task
> create one periodic task (1ms interval)
> create several non periodic tasks.
> ...
> }
>
> In one of the non periodic tasks which responsible from communication
> with user interface:
> {
> ...
> Configure EK1100
> {
> // BeckhOFF_EK1100 vendor ID and product code is copied from
> examples
> sc = ecrt_master_slave_config(master, alias, position,
> BeckhOFF_EK1100)
> }
>
> Configure EL2008
> {
> ...
> // BeckhOFF_EL2008 vendor ID and product code is copied from
> examples
> sc = ecrt_master_slave_config(master, alias, position,
> BeckhOFF_EL2008)
> // el2008_syncs struct definitions are gathered by ethercat
> tool, "cstruct" command
> ecrt_slave_config_pdos(SC, EC_END, el2008_syncs)
> el2008_PdoOffset = ecrt_slave_config_reg_pdo_entry(sc, 0x7000,
> 1, domain, NULL)
> }
>
> Configure servoOne
> {
> ...
> // LTI_ServoOnevendor ID and product code is copied from
> ethercat tool cstruct output
> sc = ecrt_master_slave_config(master, alias, position,
> LTI_ServoOne)
> // so_syncsstruct definitions are gathered by ethercat tool,
> "cstruct" command
> // Then I got XML config file and updated to use "cyclic
> synch. pos" mode.
> ecrt_slave_config_pdos(SC, EC_END, so_syncs)
>
> so_controlWOffset = ecrt_slave_config_reg_pdo_entry(sc,
> 0x6040, 0, domain, NULL)
> so_refPosOffset = ecrt_slave_config_reg_pdo_entry(sc, 0x607A,
> 0, domain, NULL)
> so_statusOffset = ecrt_slave_config_reg_pdo_entry(sc, 0x6041,
> 0, domain, NULL)
> so_actPosOffset = ecrt_slave_config_reg_pdo_entry(sc, 0x6064,
> 0, domain, NULL)
>
> // Configure DC usage for th*is drive*
> *ecrt_slave_config_dc(sc, 0x0300, 1000000, 440000,0,0)
> *
> // Do many SDO configuration by ecrt_master_sdo_download()
> // Use linux kernel task for SDO operations.
> }
>
> // Activate master
> // Linux kernel thread does the job in parallel
> activate_master_using_LinuxKernel_thread
>
> // Parallel Periodic task sees master has been activated.
> // Starts cyclic processing
>
> Enable servoOne
> {
> // using PDO, write to the control register of the drive
> // Reset Fault,
> // Do state transition to "operation enabled"
> }
> }
>
> =============================================================
> In Parallel Periodic task:
> {
> if master activated
> {
> begining_of_cycle
> {
> sem_Wait
> ecrt_master_receive(master)
> ecrt_domain_processs(domain)
> sem_Signal
>
> check_domain_state
> check_master_state
> }
>
> ...
> // Do some stuff
> ...
>
> end_of_cycle
> {
> sem_wait
> ecrt_master_application_time()
> ecrt_sync_reference_clock()
> ecrt_master_sync_slave_clock()
> ecrt_domain_queue()
> ecrt_master_send()
> sem_signal
> }
> }
> }
>
> =======================================================
> In parallel linux kernel task
> {
> ...
> activate_master_using_LinuxKernel_thread
> {
> ecrt_master_activate(master)
> domain_pd = ecrt_domain_data(domain)
> }
> ...
> }
>
>>> 3. If I connect and configure the IO devices next to the drive, at
>>> first I can set the outputs of the device. But due to the problem
>>> above I can not control the device.
>> Which problem above exact you mean?
>
> If I use DC (without configuring IO devices), I can't go to operational at first initialisation. I need to re-init the same sequence again.
> If I don't use DC I can go to operational at first initialisation.
>
>>> 4. If I re-run init sequence, this time my process domain information
>>> some how corrupts. IO device outputs are no longer in the process data.
>> What is done in your init sequence?
>> There must be something wrong with it.
>
> I wrote a pseudo code of the init sequence above. Infact I can send
> some of the real code also. But I'm not sure if you have time.
> Because I will cut the pieces from many different files, it will not
> be easy to follow :(
>
>>> 5. Regarding to a post by Graeme, I introduced two domains. One for
>>> writing, one for reading. The behaviour remained same.
>>> http://lists.etherlab.org/pipermail/etherlab-users/2012/001737.html
>> We do the same here.
>
> Do you know why we should seperate the domains? Howmany domains do you
> use for all the system?
>
>>> 6. Then I seperated the domains one for IO device, one for motor
>>> driver. Now my controller task suspends with Trap Handler: vector 14
>>> message.
>> I have no idea what the Trap Handler 14 means, we are working on a
>> mipsel based motion controller.
>> I assume there must be something wrong with your pdo-sync-setup.
>
> I get this error when I do some NULL pointer reference. But I couldn't
> locate the problem.
> If I comment out "ecrt_slave_config_dc" for the drive, I dont get trap
> 14 error.
>
>>> What is it I'm missing? How should I use DC?
>> Each DC capable device should be setup correct (AssignActivate).
>> Other non DC capable devices can be used in same domain(s) where DC
>> devices locate but without synch to real time bus cycle.
>>
>> General question:
>> Do you watch your warning and error messages (dmsg) ?
>> In case of error you will find a lot of helpful information from
>> etherlab master.
>
> Yes I check the messages but I didn't notice anything special. I'll
> look for it again.
> I hope the pseudo code above can tell something to locate the problem.
>
>> regards
>> Ralf
>>
> Best regards,
> Oguz.
>
>
>
> _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> http://lists.etherlab.org/mailman/listinfo/etherlab-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20120718/4f519c50/attachment-0004.htm>
More information about the Etherlab-users
mailing list