Hi Graeme,
thanks for the advices! We are going to try the "safe for real time" SDO
approach.
However I have looked at ecrt_slave_config_reg_pdo_entry()
implementation and adding some kind of Rx/Tx distinguishing flag should
be relatively simple because sync_configs[] already know whether it is
Rx or Tx. More work would be needed to make plumbing out of the kernel
space though and moreover we would end up with Ethercat master code with
our private changes with all the consequences for future updates.
Best Regards,
Yan
On 1/24/2013 16:02, Graeme Foot wrote:
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]>[mailto:[email protected]]*On
Behalf Of*Thomas Nelson
*Sent:*Thursday, 24 January 2013 16:15
*To:*[email protected] <mailto:[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
