Hi,
As another possible workaround (completely untested) you could try putting them in two separate domains. You might need to queue the read domain before the write domain to ensure you are reading the slave updated value rather than the newly written value. If this works, the write value can always be 1 which means you can re-arm the trigger in one cycle instead of two. Or you may need to only queue the write domain when you need to re-arm...... Graeme. ________________________________ From: Thomas Nelson [mailto:[email protected]] Sent: Friday, 25 January 2013 04:01 To: [email protected] Cc: Graeme Foot Subject: Re: [etherlab-users] Accessing same PDO for both read and write On Jan 23, 2013, at 11:21 PM, Graeme Foot wrote: Hi, I don't know the answer to the question, but as a workaround you could set up reading the value via PDO and write the value via an SDO. Writing via SDOs take approx 30ms for CoE. Regards, Graeme. ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Nelson Sent: Thursday, 24 January 2013 16:15 To: [email protected] Subject: [etherlab-users] Accessing same PDO for both read and write All, My client has a robotics system using Copley Controls Accelnet Plus drives with a digital input-triggered capture capability that we're trying to use for positioning calibration. This feature requires the ability to map the same slave CoE object for both read to detect the capture event and write to subsequently rearm the trigger. Mapping this object to both Tx and Rx PDOs appears to work correctly from the PDO mapping info returned from the master. However, when I attempt to register the corresponding mapped PDO entries in the domain, I get the same domain offset for both PDOs, preventing the application from managing them independently. The ecrt_slave_config_reg_pdo_entry() function doesn't have an argument to distinguish the direction of the PDO mapping, so is this capability not supported by the master? We're using the 1.5.0 release. We had in fact discussed this as a possible alternative, but were concerned that the SDO latency (which we didn't know previously - thanks!) could prevent the trigger from being rearmed quickly enough to avoid missing a subsequent event at the target motion rates. The system uses optical sensors for this calibration that generate rising and falling edge events that must be detected, and the r/w object in question handles trigger rearming for both types of events. Best regards, Tom Nelson Consulting Engineer Granite Computer Sciences, LLC (603) 672-8525
_______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
