sorry, I picked the wrong email address by sending the mail to <<span class="gI"><a href="mailto:etherlab-users-request@etherlab.org">etherlab-users-request@etherlab.org</a>> last night.<br><br>First of all, I agree that when the fieldbus is a kind of black box to us, we may need to threat it carefully by rewriting the buffer every cycle. But AFAIK, the EtherLAB Master actually prevents the RxPDOs being changed by slaves. So when Thomas Paoloni find his RxPDO reset to zero each cycle by a magical force, there might be something wrong in his code, maybe memory overwrite or whatever. We really need to find out the reason, instead of writing a workaround.<br>
</span><br><div class="gmail_quote">On Wed, Oct 10, 2012 at 12:52 AM, Thomas Bitsky, Jr. <span dir="ltr"><<a href="mailto:tbj@automateddesign.com" target="_blank">tbj@automateddesign.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[snip]<div class="im"><div>But Thomas Bitsky's opinion, that the RxPDOs could be changed or reset by slaves or anything else, without the developer's knowledge, really frightened me. This could certainly be a bad news for those industry robots who use my code, because of my overlook of that problem. </div>
</div><div>[/snip]</div><div><br></div><div>This is not a regular problem from me, and I was not claiming that EtherLAB itself does this to me, but I have had it happen. The AKD Servo drive from Kollmorgen does this to me all the time. I may be wrong, but I thought that the EL2004, should it not turn on the output, would reset that bit to 0. </div>
<div><br></div><div>My point was that I don't think it's a good idea to threat the fieldbus stream as a memory buffer. My usual approach is to store the value and write value for a point, and compare the two after a write, verifying that the write successfully took place.</div>
<div><br></div><div><br></div><div><div class="gmail_quote"><div class="im">On Tue, Oct 9, 2012 at 3:40 PM, Jun Yuan <span dir="ltr"><<a href="mailto:j.yuan@rtleaders.com" target="_blank">j.yuan@rtleaders.com</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">Hi Thomas Paoloni, Hi Thomas Bitsky,<br><br>I was very surprised to read the first mail from Thomas Paoloni, because having written several drivers for different EtherCAT servo amplifiers, I had never thought about that the domain data for RxPDOs must be rewritten in each cycle either. This can't be true, I thought, if this happens, I would also consider it as a bug in EtherCAT Master. <br>
<br>But Thomas Bitsky's opinion, that the RxPDOs could be changed or reset by slaves or anything else, without the developer's knowledge, really frightened me. This could certainly be a bad news for those industry robots who use my code, because of my overlook of that problem. <br>
<br>So I tried to find the answer in the EtherLab source code. And this made myself feeling a little bit
safe, because I saw that the EtherLab Master do consider whether
(domain_fmmu->dir == EC_DIR_INPUT) or (domain_fmmu->dir ==
EC_DIR_OUTPUT) before the data exchange betwen the frame and the domain.<br><br></div>And I happenly received three Beckhoff EtherCAT Terminals today. They are the coupler EK1100, the digital input EL1004 and the <span style="color:rgb(34,34,34);font-size:13px;font-family:arial,sans-serif"> the EL2004 blinks.</span> I had never seen any Beckhoff hardware before, and I was very excited to be able to test the original EtherCAT products. So I changed the configuration in the user/example/main.c a little, and made it running on my lapop. And in my environment, it doesn't matter whether "EC_WRITE_U8(domain1_pd + off_dig_out, blink ? 0x06 : 0x09);" is within or outside the if clause, the EL2004 blinks. <br>
<div><div class="h5">
<br>Could you please give me some more details, so I can rebuild the environment and observe this issue? Thanks.<br><br>Regards,<br>Jun<br><br><div class="gmail_quote">On Tue, Oct 9, 2012 at 09:42 AM, "Thomas Bitsky, Jr." <<a href="mailto:tbj@automateddesign.com" target="_blank">tbj@automateddesign.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>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"><span><font color="#888888"><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: <a href="tel:630-783-1150" value="+16307831150" target="_blank">630-783-1150</a> F: <a href="tel:630-783-1159" value="+16307831159" target="_blank">630-783-1159</a> M: <a href="tel:630-632-6679" value="+16306326679" target="_blank">630-632-6679</a></div>
<br>
</font></span></div><span><font color="#888888">
<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>
<br></font></span></blockquote></div><br><br clear="all"><br>
</div></div></blockquote></div><div><div class="h5"><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: <a href="tel:630-783-1150" value="+16307831150" target="_blank">630-783-1150</a> F: <a href="tel:630-783-1159" value="+16307831159" target="_blank">630-783-1159</a> M: <a href="tel:630-632-6679" value="+16306326679" target="_blank">630-632-6679</a></div>
<br>
</div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br>Jun Yuan<br>[Aussprache: Djün Üän]<br><br>Robotics Technology Leaders GmbH<br>Am Loferfeld 58, D-81249 München<br>Tel: +49 89 189 0465 24<br>Mobile: +49 176 2176 5238<br>
Fax: +49 89 189 0465 11<br>mailto: <a href="mailto:j.yuan@rtleaders.com" target="_blank">j.yuan@rtleaders.com</a><br><br>Umlautregel in der chinesischen Lautschrift Pinyin: Nach den Anlauten y, j, q, und x wird u als ü ausgesprochen, z.B. yu => ü, ju => dschü, qu => tschü, xu => schü.<br>