[etherlab-users] domain process data persistence

[Thomas Bitsky, Jr.]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20121008/af8c391b/attachment-0003.htm>