If you do an "ethercat slaves -v" command you will see each modules "Enable 
notLRW" value.  If the value is no then the module allows LRW "Logical Read 
Write".

Most simple modules allow LRW so can go in any suitable domain (i.e. modules 
with readonly PDO's can go in a readonly domain or a read/write domain, and 
modules with writeonly PDO's can go in a writeonly domain or a read/write 
domain).

However the Yaskawa axes have the notLRW flag set to yes which mean they do not 
allow LRW.  Therefore you need a readonly domain for the Yaskawa's readonly 
PDO's and a separate writeonly domain for the Yaskawa's writeonly PDO's.

My third domain is for all the modules that do allow LRW.  If you don't have 
any other modules you don't need it.


There can be other reasons for having separate domains also, such as logical 
groupings (especially if groups can be hot connected) or allowing different 
devices to be polled at different rates.


Regards,
Graeme.

> -----Original Message-----
> From: Rahul Deshpande [mailto:rahulg...@gmail.com] 
> Sent: Tuesday, 8 August 2017 2:10 a.m.
> To: Graeme Foot <graeme.f...@touchcut.com>
> Subject: Re: Yaskawa sigma 5 application
> 
> Hi,
> 
> Oh okay, I will check as to why its not visible on the forum. Will try 
> debugging with 'ethercat debug 1' option.
> 
> Also, you mentioned something about a third domain for different modules. 
> Will it not work if I do not define a third module ?. As of now I have 
> defined two domains (one for input and one for output).
> 
> I have also skipped the coe part from the master stack by commenting out the 
> sdo slave entry read in fsm_master.
> 
> Thank you,
> Rahul
> 
> On 8/6/17, Graeme Foot <graeme.f...@touchcut.com> wrote:
>> Hi,
>>
> I don't recall anything coming through the forum from you.  It might 
> not have worked.
>
>
> try setting the "ethercat debug 1" command (debug level 1) before 
> running your app.  Then check the dmesg log to see it you can find out 
> what it's getting stuck on.  There's also a debug 2 level, but that 
> might be a bit too much information to wade through.
>
>
> Regards,
> Graeme.
>
>
>> -----Original Message-----
>> From: Rahul Deshpande [mailto:rahulg...@gmail.com]
>> Sent: Saturday, 5 August 2017 2:17 a.m.
>> To: Graeme Foot <graeme.f...@touchcut.com>
>> Subject: Re: Yaskawa sigma 5 application
>>
>> Hi Graeme,
>>
>> Sorry for the inconvenience. I had posted on the forum but did not get 
>> any reply for a week. I found your e-mail id and thought of emailing you.
>>
>> As far as the application is concerned, I dont know why but it stalls 
>> at 'Acknowledged PRE-OP'. It does not go beyond the pre-op stage.
>>
>> Regards,
>> Rahul
>>
>>
>> On 8/3/17, Graeme Foot <graeme.f...@touchcut.com> wrote:
>>>> -----Original Message-----
>>>> From: Rahul Deshpande [mailto:rahulg...@gmail.com]
>>>> Sent: Friday, 4 August 2017 4:17 a.m.
>>>> To: Graeme Foot <graeme.f...@touchcut.com>
>>>> Subject: Yaskawa sigma 5 application
>>>>
>>>> Hi Graeme,
>>>>
>>>> Building up on the previous mail. I made a few changes to my 
>>>> application.
>>>>
>>>> I am still an amateur at this and have just been introduced to 
>>>> motion control last month. I have modified the 
>>>> example/xenomai/main.c file to suit my needs. I have attached the 
>>>> file. I am setting the PDOs as you had
>>>>
>>>> mentioned. I read on some of the etherlab group archive mails that I 
>>>> need
>>>>
>>>> to set the sdo's as well.
>>>>
>>>> My understanding is that the SDO's consist of the data that needs to 
>>>> be processed and the PDO's are just a way to communicate this data 
>>>> from slave
>>>>
>>>> to master and vice versa. Is there any specific way to configure 
>>>> these ?.
>>>>
>>>> I just intend to write a simple application.
>>>>
>>>> Thank you,
>>>> Rahul
>>>>
>>>
>>>
>>> Hi,
>>>
>>> Note: Remember to always post to the etherlab forum.
>>>
>>>
>>> 1) From you attached file it looks like you have a sigma 7 rather 
>>> than sigma
>>> 5 amp.  I haven't got my hands on one yet (in the pipeline) but 
>>> should be similar to the sigma 5.  To make sure you have the correct 
>>> PDO structures use the "ethercat struct" command.  It will output the 
>>> currently configured (or default if not changed) structures to work 
>>> with the device.  (The items below are for sigma 5, but should be
>>> similar.)
>>>
>>>
>>> 2) PDO's vs SDO's:
>>> - PDO's are the workhorse of EtherCAT.  The PDO data is communicated 
>>> every cycle.  PDO's are realtime.
>>> - SDO's are generally just used to set up initial configuration 
>>> parameters.
>>> They can be used to read/write non-PDO parameters while running, but 
>>> they are not realtime and take multiple cycles to be sent and be 
>>> returned.  They should also only be used for values that do not 
>>> change often.
>>>
>>>
>>> 3) You don't need to call these:
>>> ecrt_slave_config_sdo8( sc_dig_out_01, 0x1C12, 0, 0 ); /* clear sm 
>>> pdo
>>> 0x1c12 */
>>> ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C12, 1, 0x1601 ); /* 
>>> download pdo
>>> 1C12 index */
>>> ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C12, 2, 0x1602 ); /* 
>>> download pdo
>>> 1C12 index */
>>> ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C12, 3, 0x1606 ); /* 
>>> download pdo
>>> 1C12 index */
>>> ecrt_slave_config_sdo8( sc_dig_out_01, 0x1C12, 0, 3 ); /* set number 
>>> of RxPDO */ ecrt_slave_config_sdo8( sc_dig_out_01, 0x1C13, 0, 0 ); /* 
>>> clear sm pdo
>>> 0x1c12 */
>>> ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C13, 1, 0x1A01 ); /* 
>>> download pdo
>>> 1C13 index */
>>> ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C13, 2, 0x1A03 ); /* 
>>> download pdo
>>> 1C13 index */
>>> ecrt_slave_config_sdo16( sc_dig_out_01, 0x1C13, 3, 0x1A06 ); /* 
>>> download pdo
>>> 1C13 index */
>>> ecrt_slave_config_sdo8( sc_dig_out_01, 0x1C13, 0, 3 ); /* set number 
>>> of TxPDO */
>>>
>>> That’s what ecrt_slave_config_pdos() does.
>>>
>>>
>>> 4) There are some settings that you need to set and flash before 
>>> running the drive (and repower the drive after flashing them).
>>> - If it's an absolute motor that you will be running in incremental 
>>> mode, you need to (0x2002.1 = 1)
>>> - If you do not have limit switches you will need to disable them (in
>>> 0x250a.3 and 0x250b.0)
>>> - If you have external regen resistors, you need to set 0x2600
>>> - possibly some others I forget
>>>
>>>
>>> 5) You are blinking the first 8 bits of 0x6040.  That won't be doing 
>>> much of anything that you can see.
>>> - First thing is, is the slave in Operational mode when you go to 
>>> realtime?
>>> - Second, to enable the drive you need to go through a state machine 
>>> of setting control bits and confirming each state with status bits
>>>
>>> set: Control.EnableVoltage & Control.QuickStop wait until:
>>> Status.ReadyToSwitchOn
>>> set: Control.SwitchOn
>>> wait until: Status.SwitchedOn
>>> set: Control.EnableOperation
>>> wait until: Status.OperationEnabled
>>>
>>> You will need to set 0x6060:00 (Mode of operation) to the mode you 
>>> want to run with (e.g. 8=cyclic position)
>>>
>>> You should now be good to send target position values (0x607a:00).  I 
>>> you don't have a position generator they you could try velocity mode 
>>> (Mode of operation 9) and ramp up and down the value (for 
>>> acceleration / deceleration).
>>>
>>>
>>> Regards,
>>> Graeme.
>>>
>>>
>>>
>>>
>>>
>>>
>>
_______________________________________________
etherlab-users mailing list
etherlab-users@etherlab.org
http://lists.etherlab.org/mailman/listinfo/etherlab-users

Reply via email to