[etherlab-users] EL6688 SDOs

[John Hubbard]

Thanks for the quick reply.  I hadn't discovered the ecrt_slave_config* 
functions yet but those look a lot easier to use then what I was 
imagining setting up with the ...request_write function and state 
monitoring.  Also thanks for the explanation of SDOs vs PDOs. This helps 
a lot.


On 12/17/2015 04:29 PM, Gavin Lambert wrote:
>
> SDOs are just objects that can be accessed via acyclic (mailbox) 
> transfers.  Typically (if the slave supports CoE) all PDOs can be 
> accessed as SDOs (though usually there’s little point) but only some 
> SDOs can be accessed as PDOs.
>
> Most of the time SDOs are used purely for configuration – values that 
> you want to set once on startup and never change again.  For this 
> case, simply use the ecrt_slave_config_sdo* family of functions during 
> the configuration phase (when you’re registering PDOs) and the library 
> will take care of sending this to the device.
>
> The ecrt_sdo_request family of functions are for the other kind of SDO 
> access, where there is something that you want to read or modify 
> during live operation.  This is rarer (except for things like 
> diagnostic monitoring) as typically live changes are done via PDOs 
> instead.  But sometimes these can be useful if it’s only extremely 
> rare that you want to change something so you don’t want to “waste” 
> space in the normal domain transfer.
>
> An SDO transfer will take multiple cycles to execute (absolute minimum 
> is about 3, but it usually takes more); each slave can only process 
> one transfer at a time; and the master has a small limit on the number 
> of concurrent transfers it will actually issue, although it can hold 
> extras in a queue.
>
> *From:*etherlab-users [mailto:etherlab-users-bounces at etherlab.org] *On 
> Behalf Of *John Hubbard
> *Sent:* Friday, 18 December 2015 11:42
> *To:* etherlab-users at etherlab.org
> *Subject:* [etherlab-users] EL6688 SDOs
>
> Hello,
>
> I've not gotten my Beckhoff EL1252 and EL2252 modules mostly working 
> (I've still got some confusion WRT distributed clocks, and I'm still 
> seeing the warnings/errors I mentioned the other day).  I'm now 
> working on trying to get the EL6688 module (IEEE 1588/Precision Time 
> Protocol) up and running. From my reading of the Beckhoff 
> documentation I'm under the impression that most of the setup options 
> (e.g. Ethernet configuration and PTPv1 vs PTPv2 mode) need to be setup 
> via SDOs instead of PDOs.  (Is this what others would expect?) For 
> reference I've attached the full SDO dictionary that I obtained via 
> 'ethercat sdos'.
>
> I'm a little unclear what the difference between SDOs and PDOs is.  Is 
> the difference just the PDOs can be read/written every cycle, while 
> SDOs can only be read/written when ecrt_sdo_request_state ==> 
> EC_REQUEST_SUCCESS (following an ecrt_sdo_request_write when the state 
> is UNUSED)?  Is there a limit to how many SDOs I can request writes 
> per cycle?  From the example it looks like writing an SDO is done 
> using the same macro as writing a PDO (i.e. EC_WRITE_U32(some_sdo)), 
> is that correct?
>
> From the mailing list it looks like there was someone that attempted 
> to use an EL6688 module back in 2010.  Has anyone used one more 
> recently (i.e. with etherlabs 1.5), and if so do they have any code 
> snippets that they would be willing/able to share?
>
> Thanks.
>
>
>
> -- 
> -john
> To be or not to be, that is the question
>                  2b || !2b
> (0b10)*(0b1100010) || !(0b10)*(0b1100010)
>          0b11000100 || !0b11000100
>          0b11000100 ||  0b00111011
>                 0b11111111
> 255, that is the answer.


-- 
-john

To be or not to be, that is the question
                 2b || !2b
(0b10)*(0b1100010) || !(0b10)*(0b1100010)
         0b11000100 || !0b11000100
         0b11000100 ||  0b00111011
                0b11111111
255, that is the answer.

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