0, 25, 1000, 0);
>
>
> Graeme.
>
>
> From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf
> Of Philippe Leuba
> Sent: Friday, 18 May 2018 8:11 PM
> To: Gavin Lambert
> Cc: etherlab-users@etherlab.org
> Subject: Re: [etherlab-users
ent: Monday, 21 May 2018 12:57 PM
To: Graeme Foot ; Philippe Leuba
Cc: etherlab-users@etherlab.org
Subject: RE: [etherlab-users] Slave DC start time calculation
I would be inclined to treat that as an error, or as DC sync outputs disabled.
(It does need to treat all parameters == 0 as val
without a SYNC0 cycle time.
From: Graeme Foot [mailto:graeme.f...@touchcut.com]
Sent: Monday, 21 May 2018 12:36
To: Gavin Lambert ; Philippe Leuba
Cc: etherlab-users@etherlab.org
Subject: RE: [etherlab-users] Slave DC start time calculation
Hi,
That bit I'm unsure of. It's based on the
Monday, 21 May 2018 11:52 AM
To: Graeme Foot ; Philippe Leuba
Cc: etherlab-users@etherlab.org
Subject: RE: [etherlab-users] Slave DC start time calculation
Why are you adjusting dc_sync[0] from sync1_*? That doesn’t seem like it would
ever be a sensible thing to do, unless I’m missing something
Subject: RE: [etherlab-users] Slave DC start time calculation
I would propose the attached patch (completely untested).
This allows the sync1 offset to be used in a fashion compatible with any
existing codebase (hopefully) by adding the sync1 cycle time together with the
sync1 shift time, then
: Re: [etherlab-users] Slave DC start time calculation
Good idea, this should work for different kind of slaves and did not break
backward compatibility.
How to proceed now ?
Philippe
On May 18, 2018, at 7:24 AM, Gavin Lambert
mailto:gavin.lamb...@tomra.com>> wrote:
I don’t think it
ultiple sync1 cycle time is used to introduce any kind of shift into the
> mix.
>
> From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf
> Of Graeme Foot
> Sent: Friday, 18 May 2018 13:03
> To: Philippe Leuba ; etherlab-users@etherlab.org
Graeme Foot ; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Slave DC start time calculation
Hi Gavin,
Thanks for the detailed explanation, this explain why the code is like it is.
This works for slaves that are doing oversampling but not for mine that just
want to shift the SYNC1 a bit.
Now
00, 25, 0, 0);
>
> You have already adjusted the sync0 shift time (third to last parameter)
> anyway.
>
>
> Regards,
> Graeme.
>
>
>
> From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf
> Of Philippe Leuba
> Sent: Frida
Hi Graeme,
Thanks for your analysis that I fully agree with.
Regarding your proposition to set two last parameters to zero:
ecrt_slave_config_dc(sc, 0x0700, 50, 25, 0, 0);
This would fix the start time calculation but I can not put sync1->cycle_time
to zero because this value (1000 in
; etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Slave DC start time calculation
Hi,
This piece of code is getting a start time that is in sync with the initial app
time from a multiple of the sync0/sync1 cycle times, adjusted by the sync0
shift time.
https://download.beckhoff.com
er) anyway.
Regards,
Graeme.
From: etherlab-users [mailto:etherlab-users-boun...@etherlab.org] On Behalf Of
Philippe Leuba
Sent: Friday, 18 May 2018 7:11 AM
To: etherlab-users@etherlab.org
Subject: Re: [etherlab-users] Slave DC start time calculation
Hi,
I have changed how to calculate the sl
Hi,
I have changed how to calculate the slave start time by taking only the
sync0->cycle_time as cycle time.
The results is good and I can see in the log that the 'remainder' is almost the
same for all slaves.
@Florian: Why did you did this change on 2016-09-16 ?
Best regards
Philippe
> On
Hi All,
I can not understand how to configure correctly my slaves with the
ecrt_slave_config_dc() function.
I use nine EL7211-9014 servo controllers and the XML declarations is:
DC
DC-Synchron
#x700
0
3
0
1000
SYNC0 and SYNC1 should be fired at each cycle.
My realtime cycle is at 500u
14 matches
Mail list logo
