Re: [Etherlab-users] Cross compile the master fo ARM
Il giorno mar, 03/08/2021 alle 12.57 +, Michael Graichen ha scritto: > Hey, > > I've tried to cross-compile (ARM/i.MX7) the ec_master.ko and ec_generic.ko > modules and copied that onto my device. > I'm running Kernel 5.13.0-rt1 with the PREEMPT_RT patch. > > After loading the module with insmod "insmod ec_master.ko > main_devices=00:e0:4b:68:7f:cc" > I can see the following messages in "dmesg" > > [ 1497.798350] EtherCAT: Master driver 1.5.2 unknown > [ 1497.802642] EtherCAT: 0 masters waiting for devices. Hi Michael, this is the message I get when I forget the `main_devices` argument. The MAC addresses do not need to be valid, so with following commands: modprobe ec_master rmmod ec_master modprobe ec_master main_devices=11:11:11:11:11:11 rmmod ec_master modprobe ec_master main_devices=11:11:11:11:11:11,22:22:22:22:22:22 rmmod ec_master give me the following results: EtherCAT: Master driver 1.5.2 unknown EtherCAT: 0 masters waiting for devices. EtherCAT: Master module cleaned up. EtherCAT: Master driver 1.5.2 unknown EtherCAT: 1 master waiting for devices. EtherCAT: Master module cleaned up. EtherCAT: Master driver 1.5.2 unknown EtherCAT: 2 masters waiting for devices. EtherCAT: Master module cleaned up. Please, double check you are viewing the appropriate messages (do a `dmesg -c` before inserting the module) and that your shell/terminal emulator did not messed up your command line. Ciao. -- Nicola -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
[Etherlab-users] Cross compile the master fo ARM
Hey, I've tried to cross-compile (ARM/i.MX7) the ec_master.ko and ec_generic.ko modules and copied that onto my device. I'm running Kernel 5.13.0-rt1 with the PREEMPT_RT patch. After loading the module with insmod "insmod ec_master.ko main_devices=00:e0:4b:68:7f:cc" I can see the following messages in "dmesg" [ 1497.798350] EtherCAT: Master driver 1.5.2 unknown [ 1497.802642] EtherCAT: 0 masters waiting for devices. that came from /master/module.c => int __init ec_init_module(void) I guess "int master_count" is set to zero by default but should be set to one instead. Am i missing something? How is it set? best regards & thanks Michael -- Etherlab-users mailing list Etherlab-users@etherlab.org https://lists.etherlab.org/mailman/listinfo/etherlab-users
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
