There is no "switch". If you specify the same configuration as the slave already contains, then it just uses that configuration. If you specify a different configuration, then it will try to remap it, which may fail if the slave doesn't support remapping or if you specify something incorrect. But it's not even getting that far below -- it's failing sooner than that because your configuration is inconsistent.
Dump the actual contents of the arrays that you're passing to ecrt_slave_config_pdos and to ecrt_domain_reg_pdo_entry_list. If the master is doing something different between the two cases, it's because you're passing different data, or you're trying to configure the wrong slave. It's hard to say anything concrete without seeing the code, but for example if you look at the trace output below, you are trying to register index 0x562A in the domain, but that index isn't in the SM configuration. (It's also bit length 0, which is peculiar in itself, and strongly suggests a bug in your code.) FWIW, it is normal in an application to hard-code the content of the SM mappings for a particular device type -- or to mostly-hard-code it, if there can be some variations between actual devices such as different installed modules or different oversampling configurations requiring different input layouts. Usually the discovery/flexibility is only at the addressing level, and if the I/O layout changes or support for a new device is required then you have to update other code anyway. 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: Saturday, 14 September 2019 12:28 To: etherlab-users@etherlab.org Subject: Re: [etherlab-users] ecrt_slave_config_reg_pdo_entry() returns "No such file or directory" "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@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@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@etherlab.org >> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist >> s >> .etherlab.org%2Fmailman%2Flistinfo%2Fetherlab-users&data=02%7C01% >> 7 >> Cgavin.lambert%40tomra.com%7Cec582010c3024d2ab60a08d7379f769b%7C4308d >> 1 >> 18edd143008a37cfeba8ad5898%7C0%7C1%7C637039030350729840&sdata=tbV >> D >> 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@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%7C88454f61718c4a682ab508d738aa5f19%7C4308d1 > 18edd143008a37cfeba8ad5898%7C0%7C1%7C637040176718827830&sdata=wsQD > GWLwMyqjZBybXfn4PczJcJQEoGWB3E2UVEFLNg8%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@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%7C88454f61718c4a682ab508d738aa5f19%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637040176718827830&sdata=wsQDGWLwMyqjZBybXfn4PczJcJQEoGWB3E2UVEFLNg8%3D&reserved=0 _______________________________________________ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
