[etherlab-users] puzzle about check slave configuration

[Gavin Lambert]

The ecrt_master_slave_config* family of functions are for defining what you
are expecting to see on the network.  You only get errors if you define
something inconsistent with itself ¨C eg. if you say that device 0:5 has two
different product ids.  You do not get any errors at this point if you
specify something that is different from what is actually on the network.
(There are some scenarios, eg. hotplugging, where you want to define
configurations for devices that aren¡¯t currently on the network.)

 

To verify whether the network actually contains the slaves you¡¯re
expecting, you either need to use the ecrt_master_get_slave function to read
the current network structure, or periodically check ecrt_slave_config_state
to see if the config has been attached to a network device successfully
(this may not happen instantly).

 

From: etherlab-users [mailto:etherlab-users-bounces at etherlab.org] On Behalf
Of ???
Sent: Saturday, 21 November 2015 01:29
To: etherlab-users <etherlab-users at etherlab.org>
Subject: [etherlab-users] puzzle about check slave configuration

 

Hello, I have a new puzzle about slave configuration.
I know, when user app running, the master will check the given slave
configuration to attach the real slave.
So I want to know  if this function ecrt_master_slave_config(...) will
finally call the ecrt_master_slave_config_err(...) function?
If so, when I used correct position but wrong vendor id as the slave
configuration for input, there was nothing wrong return.
But I can see the mismatch occurred from this command ethercat config
    0:0  0x00000002/0x00000000  -  -  
Is it indicating the checking does not do in this
ecrt_master_slave_config(...) function or not call the 
ecrt_master_slave_config_err(...) function?


Thanks for tips!

--

-------------------end---------------------
am strong, therefore I am.
--Yin(^-^)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20151123/a07b0db3/attachment-0004.htm>