Really only the logging requires the time, the actual control is asynchronous. but as I see it keeping track of the relative times by a master is cumbersome, and error prone, it is far easier to have a common system clock.

To this end I have used the TIME protocol (or a hacked around version) where I have a relative mSec stamp and an absolute secs Stamp

/*
The Time based on RFC 868

The time is the number of seconds since 00:00 (midnight) 1 January 1900
GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this
base will serve until the year 2036.

For example:

   the time  2,208,988,800 corresponds to 00:00  1 Jan 1970 GMT,

             2,398,291,200 corresponds to 00:00  1 Jan 1976 GMT,

             2,524,521,600 corresponds to 00:00  1 Jan 1980 GMT,

             2,629,584,000 corresponds to 00:00  1 May 1983 GMT,

        and -1,297,728,000 corresponds to 00:00 17 Nov 1858 GMT.

*/

struct time_protocol {
	unsigned long secs;	
	unsigned int mSecs;	//while not part of the time protocol I have included it in this 
						//structure for convenience. On a time sync we will copy the secs
						//value from the appropriate CAN message and simply 0 the mSecs
						//value, in this manner we can have a mSec accurate clock time 
						//without the hassle of sending the exact mSec value to the device.
};





unsigned long funSystemTimeSync(bit mandatory_update, unsigned long syncseconds){

	if (mandatory_update == TRUE){
		synctime.secs = syncseconds;
		synctime.mSecs = 0;		//simply reset the mSecs
		return 0;				//indicates successful update
	}

	if (syncseconds >= synctime.secs){
		synctime.secs = syncseconds;
		synctime.mSecs = 0;		//simply reset the mSecs
		return 0;				//indicates successful update
	}
	else 
		synctime.mSecs = 0;		//simply reset the mSecs - there could be an error here where 
								//we reset our mSec and the message is queued or takes x-mSecs
								//to be processed by the other nodes (this is acceptable in our app)
		return synctime.secs;	//we are greater than the proposed time 
								//return our time to update rest of network

}
 

The system timekeeper will become the time keeper as per Erik's suggestion which will simply retrieve the TIME from a PC or something and broadcast on the CAN for the devices to sync to, and in the event that there is no timekeeper or it fails (or someone turns it off), I will also have each device send a time sync message (every 24 hours or other reasonable number) with the relative time embedded in it, if the time received is greater than the running time the time will update, if not then it will send another update message with its own time.

In this way the system will not be able to have the time sync backwards.

Thoughts?


Regards Marshall