[etherlab-users] Accessing same PDO for both read and write

[Graeme Foot]

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:gcsnh at granitecomputersciences.com] 
Sent: Friday, 25 January 2013 04:01
To: etherlab-users at etherlab.org
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: etherlab-users-bounces at etherlab.org
[mailto:etherlab-users-bounces at etherlab.org] On Behalf Of Thomas Nelson
Sent: Thursday, 24 January 2013 16:15
To: etherlab-users at etherlab.org
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

 

 

 





 

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