What you're proposing would be a mistake. The value coming back is the value of that object in the field. You send out a value, the slave reads it, then puts in the value that is actually there. If it just took your value and never did anything with it, you'd be blind to what is going on out in the field. The fieldbus isn't your personal memory buffer; it's feedback of what is going on in the real world.<div>
<br></div><div>Example: I turn on an output to an EL2004 output slave. When that value comes back to me, that bit is either still on, which means that the slave turned it on in the real world, or it's off, which means that the slave didn't turn on the output for some reason. But, now I know that and can do something about it. If it just left the value at 1, I'd have no idea that it hadn't turned on and my process would continue on unaware.</div>
<div><br></div><div>Yes, you do have to cache write values to verify that they get written, but that's been true for every fieldbus protocol for which I've written a driver.<br><br><div class="gmail_quote">On Mon, Oct 8, 2012 at 2:33 AM, Thomas Paoloni <span dir="ltr"><<a href="mailto:thomas@digithom.it" target="_blank">thomas@digithom.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>
<div bgcolor="#ffffff" text="#000000">
I don't agree completely with you.<br>
You're right, but if I write a certain bit out to 1 I expect that
nobody changes it's state and so, the actual value on the fieldbus
should remain 1 up to the end of the program, even if I don't write
1 continuously.<br>
I see this as a sort of bug, I'll write a workaround buffering the
output section of the domain area but I admit that I don't like this
too much ...<br>
<br>
Thanks,<br>
Thomas.<br>
<br>
<br>
<br>
<br>
On 08/10/2012 09:05, Thomas Bitsky, Jr. wrote:
<blockquote type="cite">
<p>I think you're thinking of it wrong. The data isn't cleared,
it's replaced by the actual value on the field bus. So, if you
don't write the value out to update the field bus, then the
packet gets returned with the value that is out there. </p>
<p>Thomas C Bitsky Jr<br>
Lead Developer and Application Engineer<br>
ADC | <a href="http://automateddesign.com" target="_blank">automateddesign.com</a><br>
(Sent from my mobile device.)</p>
<div class="gmail_quote">On Oct 6, 2012 4:14 AM, "Thomas Paoloni"
<<a href="mailto:thomas@digithom.it" target="_blank">thomas@digithom.it</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi all,<br>
<br>
even if I'm dealing with ethercat since more than one year,
I'm in front of a very basic question ...<br>
As from I can see, the data in master->slave direction in
the domain_pd area are not preserved from an update to
another.<br>
I'mean that I need to write out data to domain_pd area at each
cycle, even if I data is not changed and theoretically I don't
need to update some parts of the pdo area.<br>
<br>
Just applying this to the basic example in examples/user<br>
<br>
void cyclic_task()<br>
{<br>
int i;<br>
<br>
// receive process data<br>
ecrt_master_receive(master);<br>
ecrt_domain_process(domain1);<br>
<br>
// check process data state (optional)<br>
check_domain1_state();<br>
<br>
if (counter) {<br>
counter--;<br>
} else { // do this at 1 Hz<br>
counter = FREQUENCY;<br>
<br>
// calculate new process data<br>
blink = !blink;<br>
}<br>
<br>
EC_WRITE_U8(domain1_pd + off_dig_out, blink ? 0x06 :
0x09);<br>
<br>
// send process data<br>
ecrt_domain_queue(domain1);<br>
ecrt_master_send(master);<br>
}<br>
<br>
<br>
moving the EC_WRITE_U8 inside the if condition (after the
blink=!blink) will not work, because the blink bit is cleared
from the pdo area after the process data has been sent.<br>
<br>
This means that I should keep a copy of the process data and
write it on the domain1_pd each time.<br>
Is this right or I'm missing something ?<br>
<br>
<br>
Thanks,<br>
Thomas.<br>
<br>
<br>
_______________________________________________<br>
etherlab-users mailing list<br>
<a href="mailto:etherlab-users@etherlab.org" target="_blank">etherlab-users@etherlab.org</a><br>
<a href="http://lists.etherlab.org/mailman/listinfo/etherlab-users" target="_blank">http://lists.etherlab.org/mailman/listinfo/etherlab-users</a><br>
</blockquote>
</div>
</blockquote>
<br>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Thomas C. Bitsky Jr.<div>Lead Developer and Application Engineer</div><div><font color="#660000">ADC | <a href="http://automateddesign.com" target="_blank">automateddesign.com</a></font></div>
<div>P: 630-783-1150 F: 630-783-1159 M: 630-632-6679</div><br>
</div>