Re: [etherlab-users] Slave DC start time calculation

2018-05-20 Thread Graeme Foot
Yeah, that case probably is better just as an error, but the interface does not currently allow an error return value. Could just log the condition and set all values to zero. The "cycle time" name is erroneous regardless if you want to maintain backwards compatibility. I was just trying to

Re: [etherlab-users] Slave DC start time calculation

2018-05-20 Thread Gavin Lambert
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 valid but disabled.) The sync1 cycle time can’t be used directly as a sync0 cycle time anyway – the whole thing is meaningless if there isn’t a sync0 cycle time. The

Re: [etherlab-users] Slave DC start time calculation

2018-05-20 Thread Gavin Lambert
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. From: Graeme Foot [mailto:graeme.f...@touchcut.com] Sent: Monday, 21 May 2018 11:20 To: Philippe Leuba ; Gavin Lambert

Re: [etherlab-users] Slave DC start time calculation

2018-05-20 Thread Graeme Foot
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 splitting them out based on the sync0 cycle time. The only