[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 0b 255, that is the answer. SDO 0x1000, "Device type" 0x1000:00, r-r-r-, uint32, 32 bit, "Device type" SDO 0x1008, "Device name" 0x1008:00, r-r-r-, string, 48 bit, "Device name" SDO 0x1009, "Hardware version" 0x1009:00, r-r-r-, string, 16 bit, "Hardware version" SDO 0x100a, "Software version" 0x100a:00, r-r-r-, string, 16 bit, "Software version" SDO 0x1010, "Store parameters" 0x1010:00, r-r-r-, uint8, 8 bit, "SubIndex 000" 0x1010:01, rwr-r-, uint32, 32 bit, "SubIndex 001" SDO 0x1011, "Restore default parameters" 0x1011:00, r-r-r-, uint8, 8 bit, "SubIndex 000" 0x1011:01, rwrwrw, uint32, 32 bit, "SubIndex 001" SDO 0x1018, "Identity" 0x1018:00, r-r-r-, uint8, 8 bit, "SubIndex 000" 0x1018:01, r-r-r-, uint32, 32 bit, "Vendor ID" 0x1018:02, r-r-r-, uint32, 32 bit, "Product code" 0x1018:03, r-r-r-, uint32, 32 bit, "Revision" 0x1018:04, r-r-r-, uint32, 32 bit, "Serial number" SDO 0x10f0, "Backup parameter handling" 0x10f0:00, r-r-r-, uint8, 8 bit, "SubIndex 000" 0x10f0:01, r-r-r-, uint32, 32 bit, "Checksum" SDO 0x10f4, "External synchronization status" 0x10f4:00, r-r-r-, uint8, 8 bit, "SubIndex 000" 0x10f4:01, r-r-r-, type 0031, 2 bit, "Sync Mode" 0x10f4:02, r-r-r-, type , 0 bit, "SubIndex 002" 0x10f4:03, r-r-r-, type , 6 bit, "SubIndex 003" 0x10f4:04, r-r-r-, type , 0 bit, "SubIndex 004" 0x10f4:05, r-r-r-, type , 0 bit, "SubIndex 005" 0x10f4:06, r-r-r-, type , 0 bit, "SubIndex 006" 0x10f4:07, r-r-r-, type , 0 bit, "SubIndex 007" 0x10f4:08, r-r-r-, type , 0 bit, "SubIndex 008" 0x10f4:09, r-r-r-, type , 5 bit, "SubIndex 009" 0x10f4:0a, r-r-r-, type , 0 bit, "SubIndex 010" 0x10f4:0b, r-r-r-, type , 0 bit, "SubIndex 011" 0x10f4:0c, r-r-r-, type , 0 bit, "SubIndex 012" 0x10f4:0d, r-r-r-, type , 0 bit, "SubIndex 013" 0x10f4:0e, r-r-r-, bool, 1 bit, "Control value update toggle" 0x10f4:0f, r-r-r-, bool, 1 bit, "Time stamp update toggle" 0x10f4:10, r-r-r-, bool, 1 bit, "External device not connected" 0x10f4:11, r-r-r-, uint64, 64 bit, "Internal time stamp" 0x10f4:12, r-r-r-, uint64, 64 bit, "External time stamp" 0x10f4:13, r-r-r-, int32, 32 bit, "Control Value for DC Master Clock" SDO 0x10f5, "External synchronization settings" 0x10f5:00, r-r-r-, uint8, 8 bit, "SubIndex 000" 0x10f5:01, rwrwrw, bool, 1 bit, "Sync master" 0x10f5:02, rwrwrw, bool, 1 bit, "32 Bit time stamps" 0x10f5:03, rwrwrw, type , 0 bit, "SubIndex 003" 0x10f5:04, rwrwrw, type , 0 bit, "SubIndex 004" 0x10f5:05, rwrwrw, type , 0 bit, "SubIndex 005" 0x10f5:06, rwrwrw, type , 0 bit, "SubIndex 006" 0x10f5:07, rwrwrw, type , 0 bit, "SubIndex 007" 0x10f5:08, rwrwrw, type , 0 bit, "SubIndex 008" 0x10f5:09, rwrwrw, type , 0 bit, "SubIndex 009" 0x10f5:0a, rwrwrw, type , 0 bit, "SubIndex 010" 0x10f5:0b, rwrwrw, type , 0 bit, "SubIndex 011" 0x10f5:0c, rwrwrw, type , 0 bit, "SubIndex 012" 0x10f5:0d, rwrwrw, type , 0 bit, "SubIndex 013" 0x10f5:0e, rwrwrw, type , 0 bit, "SubIndex 014" 0x10f5:0f, rwrwrw, type , 0 bit, "SubIndex 015" 0x10f5:10, rwrwrw, type , 0 bit, "SubIndex 016" 0x10f5:11, rwrwrw, uint16, 16 bit, "Control Interval (ms)" 0x10f5:12, rwrwrw, uint64, 64 bit, "Additional System Time" SDO 0x1800, "TxPDO-Par External Sync" 0x1800:00, r-r-r-, uint8, 8 bit, "SubI
Re: [etherlab-users] EL6688 SDOs
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-boun...@etherlab.org] On Behalf Of John Hubbard Sent: Friday, 18 December 2015 11:42 To: etherlab-users@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 0b 255, that is the answer. ___ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
Re: [etherlab-users] EL6688 SDOs
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-boun...@etherlab.org] *On Behalf Of *John Hubbard *Sent:* Friday, 18 December 2015 11:42 *To:* etherlab-users@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 0b 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 0b 255, that is the answer. ___ etherlab-users mailing list etherlab-users@etherlab.org http://lists.etherlab.org/mailman/listinfo/etherlab-users
