Re: [Etherlab-users] Configuring EL7047 stepper driver
On 3 August 2021 6:07 pm, quoth Fontana Nicola: > This, although a bit mind twisting, is functionally equivalent to the current > one, i.e. both `ecrt_slave_config_pdos` and `autoregister_pdos` are called > for all modules but the EK1100. You're correct of course; I guess my brain was skidding over the return value comparison. > Yes, I'm not interested in storing byte or bit offsets. With "hoping" > you mean that libethercat can (at least theoretically) leave byte holes inside > the process image? That would certainly create issues here, as I am implying > everything is packed. > > > (Which, to be fair, it always should -- until you move devices around > > in your network or upgrade a device to a later revision with a different > > data > > model. > > What you have works for now, but it's brittle. But if you're happy > > with that caveat, then fine.) > > Can you expand a bit here? If the devices can be moved around I would use > aliases and if a new device cannot behave like the old one, that would > require some code rewrite. But I think those concerns are not related to the > fact I am "autoregistering" the PDO entries. API-wise, the library is only guaranteeing that the PDOs that you register appear *somewhere* in the domain memory (specifically: at the offset/pointer returned). (Technically, you only actually need to register one PDO from each SM to guarantee that the entire SM will appear -- registering every PDO is only confirming that the values also appeared in your ecrt_slave_config_pdos call; since you're iterating the same table in both cases it's a little pointless, especially if you're not saving the offsets.) EtherCAT itself requires that all PDOs within a single SM will always appear "packed" in consecutive bytes, matching the declared SM layout. It has no particular constraints between different SMs (although some slaves may misbehave if their own SMs are split between different packets, although that is supposed to be legal in general.) But a particular master is entirely free to order the SMs from different slaves however it likes, or to (for example) insert padding between SMs to ensure that each one aligns on a convenient word/dword boundary, or to group RxPDOs and TxPDOs differently (or overlap them), or to request additional SMs you didn't ask for, although usually the preference is to minimize packet size. From practical considerations, because ecrt_slave_config_reg_pdo_entry returns an offset (that cannot later be changed without restarting the configuration from scratch) and Etherlab doesn't do any alignment or extra background data (and doesn't overlap unless specifically requested), *with current implementation* you'll always end up with the domain memory being ordered with each slave's SM according to when it was first referred to by ecrt_slave_config_reg_pdo_entry and with no padding between. Doing something different is only a theoretical possibility. But it does mean that your process_image_t is tied to having exactly those slaves in exactly that order (registered order, not necessarily network order), making it brittle to changes in your design or wanting to re-use implementation for another project. My point was that for more flexibility, you could make a per-slave "process_image_t" rather than a global one -- combined with actually using the offset/pointer for the first PDO in each SM, you can make each slave a reusable component that you could repeat as many times as needed for each project, rather than a one-off. And this would also make you immune to SMs being ordered differently than you originally expected, in some theoretical future change. Gavin Lambert Senior Software Developer TOMRA Fresh Food 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. -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Il giorno mar, 03/08/2021 alle 06.39 +, Gavin Lambert ha scritto: > ... > My point was that for more flexibility, > you could make a per-slave "process_image_t" rather than a global one -- > combined with actually using the offset/pointer for the first PDO in each SM, > you can make each slave a reusable component that you could repeat as many > times as needed for each project, rather than a one-off. And this would also > make you immune to SMs being ordered differently than you originally expected, > in some theoretical future change. That makes a lot of sense: I will certainly try to adopt this model. Many thanks for all the information. Ciao. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Il giorno lun, 02/08/2021 alle 23.37 +, Gavin Lambert ha scritto:
> Yes, you're calling both now. Previously you had the "else-if" structured
> such that it wouldn't, though.
That snippet is a git repository. The original code (commit
433715bdd304) is:
if (layout->syncs != NULL && layout->n_syncs != 0 &&
ecrt_slave_config_pdos(sc, layout->n_syncs, layout->syncs) != 0) {
fprintf(stderr, "Failed to configure PDOs on slave %u-%u (%s module)\n",
alias, position, layout->name);
} else if (domain != NULL) {
autoregister_pdos(domain, sc, layout);
}
This, although a bit mind twisting, is functionally equivalent to the
current one, i.e. both `ecrt_slave_config_pdos` and `autoregister_pdos`
are called for all modules but the EK1100.
> ...
> The important point though is that it captures the pointer to the actual
> value, which you are currently discarding in your call and simply hoping that
> the data appears at the offsets you expect in your process image structure.
Yes, I'm not interested in storing byte or bit offsets. With "hoping"
you mean that libethercat can (at least theoretically) leave byte holes
inside the process image? That would certainly create issues here, as I
am implying everything is packed.
> (Which, to be fair, it always should -- until you move devices around in your
> network or upgrade a device to a later revision with a different data model.
> What you have works for now, but it's brittle. But if you're happy with that
> caveat, then fine.)
Can you expand a bit here? If the devices can be moved around I would
use aliases and if a new device cannot behave like the old one, that
would require some code rewrite. But I think those concerns are not
related to the fact I am "autoregistering" the PDO entries.
Ciao.
--
Nicola
--
Etherlab-users mailing list
Etherlab-users@etherlab.org
https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Yes, you're calling both now. Previously you had the "else-if" structured such that it wouldn't, though. ecrt_domain_reg_pdo_entry_list doesn't require a *static* array (although that's used in the examples); you can build a temporary array if you wish, although then you're back to needing a loop. The important point though is that it captures the pointer to the actual value, which you are currently discarding in your call and simply hoping that the data appears at the offsets you expect in your process image structure. (Which, to be fair, it always should -- until you move devices around in your network or upgrade a device to a later revision with a different data model. What you have works for now, but it's brittle. But if you're happy with that caveat, then fine.) Gavin Lambert Senior Software Developer TOMRA Fresh Food 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: Fontana Nicola Sent: Tuesday, 3 August 2021 12:36 am To: Gavin Lambert ; etherlab-users@etherlab.org Subject: Re: [Etherlab-users] Configuring EL7047 stepper driver Il giorno lun, 02/08/2021 alle 13.50 +0200, Fontana Nicola ha scritto: > > Il giorno dom, 01/08/2021 alle 22.55 +, Gavin Lambert ha scritto: > > Why are you calling ecrt_slave_config_pdos *OR* > > ecrt_slave_config_reg_pdo_entry? You need to do both things. > > Hi Gavin, > > I am calling both. I've just cleaned up the code and added some comment, hopefully making the intentions clearer. > > (Although you can replace the latter with > > ecrt_domain_reg_pdo_entry_list to avoid a loop in your own code.) > > Good catch, thank you: I'll check if I can drop that > `autoregister_pdos` function and will update the snippet accordingly. AFAIU, `ecrt_domain_reg_pdo_entry_list` requires another explicit static array. This is a big no from my point of view, where I am struggling to keep complexity as low as possible by using conventions instead of explicit lists. Ciao. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Il giorno lun, 02/08/2021 alle 13.50 +0200, Fontana Nicola ha scritto: > > Il giorno dom, 01/08/2021 alle 22.55 +, Gavin Lambert ha scritto: > > Why are you calling ecrt_slave_config_pdos *OR* > > ecrt_slave_config_reg_pdo_entry? You need to do both things. > > Hi Gavin, > > I am calling both. I've just cleaned up the code and added some comment, hopefully making the intentions clearer. > > (Although you can replace the latter with > > ecrt_domain_reg_pdo_entry_list to avoid a loop in your own code.) > > Good catch, thank you: I'll check if I can drop that `autoregister_pdos` > function and will update the snippet accordingly. AFAIU, `ecrt_domain_reg_pdo_entry_list` requires another explicit static array. This is a big no from my point of view, where I am struggling to keep complexity as low as possible by using conventions instead of explicit lists. Ciao. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Il giorno dom, 01/08/2021 alle 22.55 +, Gavin Lambert ha scritto: > Why are you calling ecrt_slave_config_pdos *OR* > ecrt_slave_config_reg_pdo_entry? You need to do both things. Hi Gavin, I am calling both. `ecrt_slave_config_pdos` is called only when there is at least one sync manager to configure (some node, e.g. EK1100, does not have any sync manager) while `ecrt_slave_config_reg_pdo_entry` is called only if `ecrt_slave_config_pdos` has been successful (returned 0) and the domain is defined (should always be). > (Although you can replace the latter with > ecrt_domain_reg_pdo_entry_list to avoid a loop in your own code.) Good catch, thank you: I'll check if I can drop that `autoregister_pdos` function and will update the snippet accordingly. Ciao. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Why are you calling ecrt_slave_config_pdos *OR* ecrt_slave_config_reg_pdo_entry? You need to do both things. (Although you can replace the latter with ecrt_domain_reg_pdo_entry_list to avoid a loop in your own code.) Gavin Lambert Senior Software Developer TOMRA Fresh Food 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: Fontana Nicola Sent: Sunday, 1 August 2021 8:38 am To: Graeme Foot ; etherlab-users@etherlab.org Subject: Re: [Etherlab-users] Configuring EL7047 stepper driver Il giorno lun, 26/07/2021 alle 07.00 +0200, Fontana Nicola ha scritto: > ... > I will do my homeworks and report back for future reference. > ... I can confirm that, by moving the PDO handling into the application, things started working as expected. Here is the updated snippet: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2F-%2Fsnippets%2F2155802data=04%7C01%7Cgavin.lambert%40tomra.com%7C020593bd03294f1d6ccf08d954631658%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637633606834855034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=nLGnNTU%2F52J5y71UJ%2FPsKMsrAv8ASYVFE5HQos8cBxE%3Dreserved=0 The shell script is now used only for bootstrapping the EL7047. All 0x8nnn:nn entries in the object dictionary seem to be stored in some non-volatile memory (no idea this is customary or mandated by some standard), so that script should be called only on new devices. The manual handling of PDOs on the C side is really tedious and error-prone, so I can understand Gavin's suggestion of trying to configure as much as possible before `ethercat cstruct`, but I'm confident some kind of abstraction is possible (see e.g. the `SlaveLayout` struct in `el7047.c` for details). Thank you again for your help. Ciao. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.etherlab.org%2Fmailman%2Flistinfo%2Fetherlab-usersdata=04%7C01%7Cgavin.lambert%40tomra.com%7C020593bd03294f1d6ccf08d954631658%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637633606834855034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=09hYJykWoNSbxHGWss%2Brmww8iycr42NTxi1XytKecVw%3Dreserved=0 -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Il giorno lun, 26/07/2021 alle 07.00 +0200, Fontana Nicola ha scritto: > ... > I will do my homeworks and report back for future reference. > ... I can confirm that, by moving the PDO handling into the application, things started working as expected. Here is the updated snippet: https://gitlab.com/-/snippets/2155802 The shell script is now used only for bootstrapping the EL7047. All 0x8nnn:nn entries in the object dictionary seem to be stored in some non-volatile memory (no idea this is customary or mandated by some standard), so that script should be called only on new devices. The manual handling of PDOs on the C side is really tedious and error-prone, so I can understand Gavin's suggestion of trying to configure as much as possible before `ethercat cstruct`, but I'm confident some kind of abstraction is possible (see e.g. the `SlaveLayout` struct in `el7047.c` for details). Thank you again for your help. Ciao. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Broadly speaking, there's three different kinds of slave. The most basic have fixed PDO configuration and assignment. If these implement CoE at all (which is also optional), you can't change any part of the PDO layout. The middle tier (reasonably common in slaves that implement CoE at all) have variable PDO assignment but fixed configuration. This means that you cannot change the contents of the PDOs but you can select which of them to include in your domain (although not always freely -- many slaves have mutually exclusive PDOs or specific ordering/size requirements or other such limitations). Lastly there are those that do support changing the PDO configuration as well as assignment. These are very rare (typically just things like PLCs and other highly programmable slaves). For the former, you just "ethercat cstruct" and that's the only layout you'll ever get. For the other two, you can do some manipulation before you "ethercat cstruct". But that manipulation only happens at "pre-commission" time (when you're writing your application) -- it never happens at actual run-live. The table that is generated by "ethercat cstruct" encapsulates all of the PDO configuration and assignment, and when you use this table properly (see the examples) you don't have any "manual" writes to the PDO assignment or configuration objects at all in your code; that's taken care of by the Etherlab master itself. The ecrt_slave_config_sdo* calls are only for "extra" not-PDO-related configuration that your slave may require. Gavin Lambert Senior Software Developer TOMRA Fresh Food 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: Fontana Nicola Sent: Monday, 26 July 2021 5:21 pm To: Gavin Lambert ; Graeme Foot ; etherlab-users@etherlab.org Subject: Re: [Etherlab-users] Configuring EL7047 stepper driver Il giorno lun, 26/07/2021 alle 04.54 +, Gavin Lambert ha scritto: > ... > It's not really something you can do from a bash script. Hi Gavin, yes, I learnt it the hard way. That particular device has fixed PDO mappings and settings, i.e. all 0x1[468A]? entries are read-only. The only relevant parameters I can touch are the PDO assignement registers. Coming from CANopen I thought anything can be done by just manipulating the object dictionary but... well, this is not the case. Thank you again. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
You can also configure the slave to the desired configuration (either manually via "ethercat download" command line or with another master such as TwinCAT) before you use "ethercat cstruct" to generate your desired PDO layout (but do still read through it to verify that it is as expected). This may or may not be simpler than just modifying the default cstruct tables to your desired config, depending on various factors. After that, as Graeme says, you should write your application code to do the necessary configuration assuming that no "ethercat" commands have previously been run. Reboot your slave before testing your app to ensure that it's not depending on some previous manual configuration, and read the example code (especially the "user" example). It's not really something you can do from a bash script. Gavin Lambert Senior Software Developer TOMRA Fresh Food 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: Etherlab-users On Behalf Of Graeme Foot Sent: Monday, 26 July 2021 1:47 pm To: Fontana Nicola ; etherlab-users@etherlab.org Subject: Re: [Etherlab-users] Configuring EL7047 stepper driver Hi Nicola, The first thing is don't try to configure slaves via the ethercat command line utility. You need to run an application (see the examples folder for various example applications). The second thing is don't try to manually configure each slave by direct SDO calls, there are functions that do all of that for you that you call as part of the application. The applications first step is to configure the slaves using for example: ecrt_master_get_slave ecrt_master_slave_config ecrt_slave_config_pdos ecrt_slave_config_create_sdo_request ecrt_slave_config_reg_pdo_entry ecrt_slave_config_sdo8 etc ecrt_slave_config_dc A devices default configuration can be retrieved using the "ethercat cstruct" command. You can then modify it if your slave allows modification. You can download the slaves esi file from Beckhoff if you want to use a non-standard configuration, using it as a reference to set up your own cstruct data. Once ready, the application calls ecrt_master_activate() and then calls the following commands (as a minimum) in a realtime loop: ecrt_master_receive ecrt_domain_process ecrt_domain_queue ecrt_master_send The application will bring the slaves up from PREOP to OP, applying the configuration along the way. If a slave is repowered the master will automatically re-apply the configuration and bring it back to OP. Regards, Graeme -Original Message- From: Etherlab-users On Behalf Of Fontana Nicola Sent: Sunday, 25 July 2021 01:02 To: etherlab-users@etherlab.org Subject: [Etherlab-users] Configuring EL7047 stepper driver Hi all, I think this issue is not related to the ethercat software per-se but maybe someone has already met something similar or can point me into the right direction. I'm trying to configure the EL7047 stepper driver in position controller mode without encoder (by default it is in velocity mode): https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.beckhoff.com%2Fen-en%2Fproducts%2Fi-o%2Fethercat-terminals%2Fel7xxx-compact-drive-technology%2Fel7047.htmldata=04%7C01%7Cgavin.lambert%40tomra.com%7C16a57fd89b504bb5809808d94fd745eb%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637628608287133729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=7nrcZ%2BRZV042Qzmhkyow%2B5Dam266ZgyJp7bRKX%2BZe84%3Dreserved=0 No matter what: it stays in PREOP state after having configured it. Whenever I try to put it in SAFEOP/OP I get: Failed to set SAFEOP state, slave refused state change (PREOP + ERROR). AL status message 0x001E: "Invalid input configuration". Here is the full script I'm using: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2F-%2Fsnippets%2F2153453data=04%7C01%7Cgavin.lambert%40tomra.com%7C16a57fd89b504bb5809808d94fd745eb%7C4308d118edd143008a37cfeba8ad5898%7C0%7C1%7C637628608287133729%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=Amp%2FeLCSJ7gRo6mLXMdACw8az8EbiNrurOTWdO0vcvc%3Dreserved=0 It runs successfully and I am sure the settings are changed (I checked them many times). For a couple of parameters, with a datatype smaller than a byte but bigger than boolean, I had to explicitely set the datatype to `uint8`, and AFAIK this is the only thing that "stinks". The Bec
Re: [Etherlab-users] Configuring EL7047 stepper driver
Il giorno lun, 26/07/2021 alle 04.54 +, Gavin Lambert ha scritto: > ... > It's not really something you can do from a bash script. Hi Gavin, yes, I learnt it the hard way. That particular device has fixed PDO mappings and settings, i.e. all 0x1[468A]? entries are read-only. The only relevant parameters I can touch are the PDO assignement registers. Coming from CANopen I thought anything can be done by just manipulating the object dictionary but... well, this is not the case. Thank you again. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Il giorno lun, 26/07/2021 alle 01.46 +, Graeme Foot ha scritto: > Hi Nicola, > > The first thing is don't try to configure slaves via the ethercat command line > utility. You need to run an application (see the examples folder for various > example applications). > The second thing is don't try to manually configure each slave by direct SDO > calls, there are functions that do all of that for you that you call as part > of the application. Hi Graeme, from a previous answer [0] I got the exact opposite impression, i.e. that I should configure whatever possible with the CLI and only then do `ethercat cstruct`. After re-reading, I think I misunderstood what "pre-configuration" means. I think you are right though, because there are many APIs with sound names, particularly the pdo related one. I will do my homeworks and report back for future reference. Thank you. -- Nicola [0] https://lists.etherlab.org/pipermail/etherlab-users/2021-March/019105.html -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [Etherlab-users] Configuring EL7047 stepper driver
Hi Nicola, The first thing is don't try to configure slaves via the ethercat command line utility. You need to run an application (see the examples folder for various example applications). The second thing is don't try to manually configure each slave by direct SDO calls, there are functions that do all of that for you that you call as part of the application. The applications first step is to configure the slaves using for example: ecrt_master_get_slave ecrt_master_slave_config ecrt_slave_config_pdos ecrt_slave_config_create_sdo_request ecrt_slave_config_reg_pdo_entry ecrt_slave_config_sdo8 etc ecrt_slave_config_dc A devices default configuration can be retrieved using the "ethercat cstruct" command. You can then modify it if your slave allows modification. You can download the slaves esi file from Beckhoff if you want to use a non-standard configuration, using it as a reference to set up your own cstruct data. Once ready, the application calls ecrt_master_activate() and then calls the following commands (as a minimum) in a realtime loop: ecrt_master_receive ecrt_domain_process ecrt_domain_queue ecrt_master_send The application will bring the slaves up from PREOP to OP, applying the configuration along the way. If a slave is repowered the master will automatically re-apply the configuration and bring it back to OP. Regards, Graeme -Original Message- From: Etherlab-users On Behalf Of Fontana Nicola Sent: Sunday, 25 July 2021 01:02 To: etherlab-users@etherlab.org Subject: [Etherlab-users] Configuring EL7047 stepper driver Hi all, I think this issue is not related to the ethercat software per-se but maybe someone has already met something similar or can point me into the right direction. I'm trying to configure the EL7047 stepper driver in position controller mode without encoder (by default it is in velocity mode): https://www.beckhoff.com/en-en/products/i-o/ethercat-terminals/el7xxx-compact-drive-technology/el7047.html No matter what: it stays in PREOP state after having configured it. Whenever I try to put it in SAFEOP/OP I get: Failed to set SAFEOP state, slave refused state change (PREOP + ERROR). AL status message 0x001E: "Invalid input configuration". Here is the full script I'm using: https://gitlab.com/-/snippets/2153453 It runs successfully and I am sure the settings are changed (I checked them many times). For a couple of parameters, with a datatype smaller than a byte but bigger than boolean, I had to explicitely set the datatype to `uint8`, and AFAIK this is the only thing that "stinks". The Beckhoff manual keeps reporting TwinCAT screenshots instead of explaining how things work but (1) I do not have access to TwinCAT and (2) I have less than zero interest in depending on a software blob. Not sure it is relevant, but here is the output of `ethercat sl`: 0 0:0 PREOP + EK1100 EtherCAT-Koppler (2A E-Bus) 1 0:1 PREOP + EL1809 16K. Dig. Eingang 24V, 3ms 2 0:2 PREOP + EL1809 16K. Dig. Eingang 24V, 3ms 3 0:3 PREOP + EL1809 16K. Dig. Eingang 24V, 3ms 4 0:4 PREOP + EL2809 16K. Dig. Ausgang 24V, 0.5A 5 0:5 PREOP + EL2808 8Ch. Dig. Output 24V, 0.5A 6 0:6 PREOP + EL7047 1K. Schrittmotor-Endstufe (50V, 5A) Ciao. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
