[etherlab-users] domain process data persistence

Jun Yuan j.yuan at rtleaders.com
Wed Oct 10 09:41:43 CEST 2012 

sorry, I picked the wrong email address by sending the mail to <
etherlab-users-request at etherlab.org> last night.

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.

On Wed, Oct 10, 2012 at 12:52 AM, Thomas Bitsky, Jr. <
tbj at automateddesign.com> wrote:

> [snip]
> 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.
> [/snip]
>
> 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.
>
> 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.
>
>
> On Tue, Oct 9, 2012 at 3:40 PM, Jun Yuan <j.yuan at rtleaders.com> wrote:
>
>> Hi Thomas Paoloni, Hi Thomas Bitsky,
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> And I happenly received three Beckhoff EtherCAT Terminals today. They are
>> the coupler EK1100, the digital input EL1004 and the  the EL2004 blinks. 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.
>>
>> Could you please give me some more details, so I can rebuild the
>> environment and observe this issue? Thanks.
>>
>> Regards,
>> Jun
>>
>> On Tue, Oct 9, 2012 at 09:42 AM, "Thomas Bitsky, Jr." <
>> tbj at automateddesign.com> wrote:
>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> On Mon, Oct 8, 2012 at 2:33 AM, Thomas Paoloni <thomas at digithom.it>wrote:
>>>
>>>> **
>>>> I don't agree completely with you.
>>>> 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.
>>>> 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 ...
>>>>
>>>> Thanks,
>>>> Thomas.
>>>>
>>>>
>>>>
>>>>
>>>> On 08/10/2012 09:05, Thomas Bitsky, Jr. wrote:
>>>>
>>>> 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.
>>>>
>>>> Thomas C Bitsky Jr
>>>> Lead Developer and Application Engineer
>>>> ADC | automateddesign.com
>>>> (Sent from my mobile device.)
>>>> On Oct 6, 2012 4:14 AM, "Thomas Paoloni" <thomas at digithom.it> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> even if I'm dealing with ethercat since more than one year, I'm in
>>>>> front of a very basic question ...
>>>>> As from I can see, the data in master->slave direction in the
>>>>> domain_pd area are not preserved from an update to another.
>>>>> 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.
>>>>>
>>>>> Just applying this to the basic example in examples/user
>>>>>
>>>>> void cyclic_task()
>>>>> {
>>>>>     int i;
>>>>>
>>>>>     // receive process data
>>>>>     ecrt_master_receive(master);
>>>>>     ecrt_domain_process(domain1);
>>>>>
>>>>>     // check process data state (optional)
>>>>>     check_domain1_state();
>>>>>
>>>>>     if (counter) {
>>>>>         counter--;
>>>>>     } else { // do this at 1 Hz
>>>>>         counter = FREQUENCY;
>>>>>
>>>>>         // calculate new process data
>>>>>         blink = !blink;
>>>>>     }
>>>>>
>>>>>     EC_WRITE_U8(domain1_pd + off_dig_out, blink ? 0x06 : 0x09);
>>>>>
>>>>>     // send process data
>>>>>     ecrt_domain_queue(domain1);
>>>>>     ecrt_master_send(master);
>>>>> }
>>>>>
>>>>>
>>>>> 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.
>>>>>
>>>>> This means that I should keep a copy of the process data and write it
>>>>> on the domain1_pd each time.
>>>>> Is this right or I'm missing something ?
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Thomas.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> etherlab-users mailing list
>>>>> etherlab-users at etherlab.org
>>>>> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Thomas C. Bitsky Jr.
>>> Lead Developer and Application Engineer
>>> ADC | automateddesign.com
>>> P: 630-783-1150 F: 630-783-1159 M: 630-632-6679
>>>
>>>
>>> _______________________________________________
>>> etherlab-users mailing list
>>> etherlab-users at etherlab.org
>>> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>>>
>>>
>>
>>
>>
>
>
> --
> Thomas C. Bitsky Jr.
> Lead Developer and Application Engineer
> ADC | automateddesign.com
> P: 630-783-1150 F: 630-783-1159 M: 630-632-6679
>
>


-- 
Jun Yuan
[Aussprache: Djün Üän]

Robotics Technology Leaders GmbH
Am Loferfeld 58, D-81249 München
Tel: +49 89 189 0465 24
Mobile: +49 176 2176 5238
Fax: +49 89 189 0465 11
mailto: j.yuan at rtleaders.com

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ü.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20121010/c11538a1/attachment-0004.htm>

More information about the Etherlab-users mailing list