[etherlab-users] ecrt_slave_config_reg_pdo_entry() returns "No such file or directory"
Gary Grobe
ggrobe at houstonmechatronics.com
Sat Sep 14 02:27:47 CEST 2019
"When you call ecrt_slave_config_pdos, you are telling Etherlab either
what PDOs the slave already uses in its default PDO assignment, or which
ones you *want* the slave to use."
In my case, I'm calling ecrt_slave_config_pdos telling Etherlab about
the PDO's using the default assignments, and also expecting to use them.
Is there a difference code-wise between both sides of that "or" in your
response?
Using just a single device, I have a test program which works perfectly.
None of the PDO's are remapped and so when
ecrt_domain_reg_pdo_entry_list() is called, it finds the entries and all
is good. The order of calls is:
* ecrt_request_master()
* ecrt_master_create_domain()
* ecrt_ecrt_master_slave_config()
* ecrt_slave_config_pdos()
* ecrt_domain_reg_pdo_entry_list()
I have a second program that makes the exact same calls, and in this
case, the PDO's are being remapped and so I'm trying to understand the
"switch" that causes one piece of code to NOT remap entries, and another
with the exact same calls to remap entries. In this case, the call to
ecrt_domain_reg_pdo_entry_list() is failing because it's not finding the
expected entries as shown in the output below of the previous post.
Having said that, there is one difference between the two programs that
I'm pretty certain is causing the issue, but not understanding the why.
The second program up-front, before calling ecrt_request_master(),
performs an auto-discovery of the devices on the network and using this
info, rebuilds the exact same structures 'ethercat cstruct' outputs.
This is then fed into the same call stack. To do this, it uses the same
functionality as that of the ethercat tool. The other program (that
works fine) has the syncs, pdos, entries, and domains hard-coded,
basically with the output of 'ethercat cstruct' embedded.
Can you provide clarification about the "switch" that might cause one
program to remap entries whereas the other does not while using the same
call stack? I've also tried resetting sockets, and making ioctl calls to
reboot and rescan the device between discover and configuration to no
avail, but haven't quite exhausted these attempts yet, still may be
doing something wrong time-wise.
Thanks,
On 9/12/19 7:09 PM, Gavin Lambert wrote:
> Each sync manager contains a set of PDOs, which are potentially exchanged in the domain datagram. A slave boots up with a typical configuration (and basic slaves do not change it), but some slaves allow the master to select a different set of PDOs for each SM, when they require an atypical configuration.
>
> When you call ecrt_slave_config_pdos, you are telling Etherlab either what PDOs the slave already uses in its default PDO assignment, or which ones you *want* the slave to use. This internally makes those ecrt_slave_config_sync_manager and ecrt_slave_config_pdo_assign_add calls that you see below. And this will change the slave's "default mapping" until you reboot the slave.
>
> You need to make sure that this is consistent both with the PDOs that the slave will allow you to configure and with the ones that you are intending to register in your domain. As I said before.
>
>
> Gavin Lambert
> Senior Software Developer
>
>
>
>
> COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland 1061 | New Zealand
> Switchboard: +49 2630 96520 | https://www.tomra.com
>
> The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.
> -----Original Message-----
> From: Gary Grobe
> Sent: Friday, 13 September 2019 04:37
> To: etherlab-users at etherlab.org
> Subject: Re: [etherlab-users] ecrt_slave_config_reg_pdo_entry() returns "No such file or directory"
>
> Let me ask this ... master/slave_config.c has the following function.
>
> void ec_slave_config_load_default_mapping(
> const ec_slave_config_t *sc,
> ec_pdo_t *pdo
> )
> {
>
> And just a few lines down there's this comment.
>
> // find PDO in any sync manager (it could be reassigned later)
> for (i = 0; i < sc->slave->sii_image->sii.sync_count; i++) {
> sync = &sc->slave->sii_image->sii.syncs[i];
>
> Can anyone comment as to why/how a PDO could possibly be reassigned at a later time?
>
> I ask because with only one device online (master debug output below), notice that the 2nd subindex (after a proper "Entry") has changed and therefore not being found. I'd expect to see 0x60FE instead of 0x562A and 0x01 as the subindex.
>
> ---
> [177023.668497] EtherCAT: Requesting master 0...
> [177023.668503] EtherCAT DEBUG 0: IDLE -> OPERATION.
> [177023.668506] EtherCAT: Successfully requested master 0.
> [177023.668516] EtherCAT DEBUG 0: ecrt_master_create_domain(master =
> 0x00000000c7ddebfa)
> [177023.668519] EtherCAT DEBUG 0: Created domain 0.
> [177023.668534] EtherCAT DEBUG 0: ecrt_master_slave_config(master = 0x00000000c7ddebfa, alias = 0, position = 0, vendor_id = 0x0000009a, product_code = 0x00030924) [177023.668537] EtherCAT DEBUG 0: Creating slave configuration for 0:0, 0x0000009A/0x00030924.
> [177023.668542] EtherCAT DEBUG 0 0:0: Attached slave main-0.
> [177023.670926] EtherCAT DEBUG 0 0:0: ecrt_slave_config_sync_manager(sc = 0x00000000d8f76f5b, sync_index = 0, dir = 1, watchdog_mode = 2) [177023.670938] EtherCAT DEBUG 0 0:0:
> ecrt_slave_config_pdo_assign_clear(sc = 0x00000000d8f76f5b, sync_index = 0) [177023.670945] EtherCAT DEBUG 0 0:0: ecrt_slave_config_sync_manager(sc = 0x00000000d8f76f5b, sync_index = 1, dir = 2, watchdog_mode = 2) [177023.670952] EtherCAT DEBUG 0 0:0:
> ecrt_slave_config_pdo_assign_clear(sc = 0x00000000d8f76f5b, sync_index = 1) [177023.670959] EtherCAT DEBUG 0 0:0: ecrt_slave_config_sync_manager(sc = 0x00000000d8f76f5b, sync_index = 2, dir = 1, watchdog_mode = 1) [177023.670971] EtherCAT DEBUG 0 0:0:
> ecrt_slave_config_pdo_assign_clear(sc = 0x00000000d8f76f5b, sync_index = 2) [177023.670981] EtherCAT DEBUG 0 0:0:
> ecrt_slave_config_pdo_assign_add(sc = 0x00000000d8f76f5b, sync_index = 2, pdo_index = 0x1600) [177023.670984] EtherCAT DEBUG 0 0:0: Loading default mapping for PDO 0x1600.
> [177023.670988] EtherCAT DEBUG 0 0:0: Entry 0x607A:00.
> [177023.670990] EtherCAT DEBUG 0 0:0: Entry 0x60FE:01.
> [177023.670993] EtherCAT DEBUG 0 0:0: Entry 0x6040:00.
> [177023.671001] EtherCAT DEBUG 0 0:0:
> ecrt_slave_config_pdo_mapping_clear(sc = 0x00000000d8f76f5b, pdo_index =
> 0x1600)
> [177023.671013] EtherCAT DEBUG 0 0:0:
> ecrt_slave_config_pdo_mapping_add(sc = 0x00000000d8f76f5b, pdo_index = 0x1600, entry_index = 0x607A, entry_subindex = 0x00, entry_bit_length = 32) [177023.671023] EtherCAT DEBUG 0 0:0:
> ecrt_slave_config_pdo_mapping_add(sc = 0x00000000d8f76f5b, pdo_index = 0x1600, entry_index = 0x562A, entry_subindex = 0x00, entry_bit_length = 0) [177023.671098] EtherCAT DEBUG 0 0:0:
> ecrt_slave_config_pdo_mapping_add(sc = 0x00000000d8f76f5b, pdo_index = 0x1600, entry_index = 0x0021, entry_subindex = 0x00, entry_bit_length = 0)
>
> On 9/9/19 6:55 PM, Gavin Lambert wrote:
>> You will receive that error if you specify a PDO index/subindex that does not exist in the slave, according to the configuration that Etherlab is aware of at the time.
>>
>> This either requires a slave to already be present in the network and scanned with that PDO already included in its default PDO set, or it requires you to have previously called ecrt_slave_config_pdos() with the slave's current/desired SM layout.
>>
>> It's recommended to do the latter, as it also works when the slaves are not yet online -- and it gives you the ability to select PDOs which are not in the slave's default set. Although of course some slaves have restrictions on which PDOs you can select together, and others do not let you change the default PDO set -- but you can still explicitly specify it via ecrt_slave_config_pdos() so that you can create a configuration without needing the slaves to be online.
>>
>> See the example apps. Also see the code generated by "ethercat cstruct".
>>
>>
>> Gavin Lambert
>> Senior Software Developer
>>
>>
>>
>>
>> COMPAC SORTING EQUIPMENT LTD | 4 Henderson Pl | Onehunga | Auckland
>> 1061 | New Zealand
>> Switchboard: +49 2630 96520 | https://www.tomra.com
>>
>> The information contained in this communication and any attachment is confidential and may be legally privileged. It should only be read by the person(s) to whom it is addressed. If you have received this communication in error, please notify the sender and delete the communication.
>> -----Original Message-----
>> From: Gary Grobe
>> Sent: Tuesday, 10 September 2019 11:24
>> To: etherlab-users at etherlab.org
>> Subject: [etherlab-users] ecrt_slave_config_reg_pdo_entry() returns "No such file or directory"
>>
>> I'm working a new userspace app with etherlab and have managed to discover slaves and configure PDO's and am now at the point of doing mass registrations of PDO's.
>>
>> In domain.c is the ecrt_domain_reg_pdo_entry_list() function which iterates through an array of ec_pdo_entry_reg_t's. As it iterates through the array, the call stack is roughly ...
>>
>> ecrt_domain_reg_pdo_entry_list()
>> ecrt_master_slave_config()
>> ec_master_add_slave_config()
>> ecrt_slave_config_reg_pdo_entry()
>> ioctl()
>>
>> The first of seven ec_pdo_entry_reg_t objects in the array was
>> successful. However, on the second iteration of the input array, the
>> result (errno) from the call to ioctl() in
>> ecrt_slave_config_reg_pdo_entry() of slave_config.c is failing with "No such file or directory".
>>
>> I've triple checked the inputs which appear to be correct, but recall
>> reading somewhere's that there may be checks to the capabilities of
>> ioctl() calls handling a device which I'm not clear on. I was hoping someone might be able to comment or explain if this is the case or have other ideas as to what might be going on?
>>
>> The exact message is:
>> "Failed to register PDO entry: No such file or directory"
>>
>>
>>
>>
>> --
>> _The contents of this email message and any attachments are intended
>> solely for the addressee(s). This message (including any attachments)
>> may contain confidential, proprietary, privileged and/or private
>> information. The information is intended to be for the use of the
>> individual or entity designated above. If you are not the intended
>> recipient of this message, please notify the sender immediately, and
>> delete the message and any attachments. _Any disclosure,
>> reproduction, distribution or other use of this message or any
>> attachments by an individual or entity other than the intended
>> recipient is prohibited. __
>> _______________________________________________
>> etherlab-users mailing list
>> etherlab-users at etherlab.org
>> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
>> .etherlab.org%2Fmailman%2Flistinfo%2Fetherlab-users&data=02%7C01%7
>> Cgavin.lambert%40tomra.com%7Cec582010c3024d2ab60a08d7379f769b%7C4308d1
>> 18edd143008a37cfeba8ad5898%7C0%7C1%7C637039030350729840&sdata=tbVD
>> pSClW%2FxocI3dFMiYlQWV5s8Yb22Df3YddkHna6U%3D&reserved=0
> --
> _The contents of this email message and any attachments are intended solely for the addressee(s). This message (including any attachments) may contain confidential, proprietary, privileged and/or private information. The information is intended to be for the use of the individual or entity designated above. If you are not the intended recipient of this message, please notify the sender immediately, and delete the message and any attachments. _Any disclosure, reproduction, distribution or other use of this message or any attachments by an individual or entity other than the intended recipient is prohibited. __ _______________________________________________
> etherlab-users mailing list
> etherlab-users at etherlab.org
> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.etherlab.org%2Fmailman%2Flistinfo%2Fetherlab-users&data=02%7C01%7Cgavin.lambert%40tomra.com%7Cec582010c3024d2ab60a08d7379f769b%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637039030350729840&sdata=tbVDpSClW%2FxocI3dFMiYlQWV5s8Yb22Df3YddkHna6U%3D&reserved=0
--
_The contents of this email message and any attachments are intended solely
for the addressee(s). This message (including any attachments) may contain
confidential, proprietary, privileged and/or private information. The
information is intended to be for the use of the individual or entity
designated above. If you are not the intended recipient of this message,
please notify the sender immediately, and delete the message and any
attachments. _Any disclosure, reproduction, distribution or other use of
this message or any attachments by an individual or entity other than the
intended recipient is prohibited. __
More information about the Etherlab-users
mailing list