etc6849,
If I understand the serial Configuration properties correctly:
RxTextLineTerminators indicates the "end-of-message" terminator(s) for text-based (ASCII) data. Default values are: 0D 0A 00 (CR LF NULL).
RxTextBufferLines indicates the number of lines of text-based data that will be buffered. Default value is 60.
Based on the default values, Premise will buffer sixty lines ("text strings") of incoming data where each line is terminated by a CR, LF, or NULL character. I don't know why you are losing 2-way comms upon reboot, but I'd be surprised if RxTextBufferLines is the culprit. It doesn't mean it ain't so ... just that I'd be surprised.
You indicated "
The only way I can get 2 way communication again is to remove the device, then re add it". I believe the clue lies in what happens when the device driver is first installed. What happens initially that may not be happening when Premise is restarted and this is what leads to the comms failure.
I'm going to state the obvious here: Losing the ability to receive data from the Onkyo indicates that Premise may have, after rebooting, re-initialized its serial port configuration parameters to default values that are incompatible with your requirements. Compare all serial configuration properties before and after a reboot and ensure they are identical. Maybe one of them doesn't survive the reboot (i.e. it is not "Persistent") and reverts to an undesired default value.
If all it takes to correct the problem is a 'magic spell' (i.e. twiddling the RxTextBufferLines property causes something internally to be snapped to attention), you can add the spell into
OnChangeOnInit so it'll be issued upon driver initialization.
Code:
' Twiddle RxTextBufferLines because it appears to fix a 2-way comms problem
this.RxTextBufferLines=60
this.RxTextBufferLines=80
this.RxTextBufferLines=60
You may also want to have a look at the code in the
Home Electronics IRA driver. I paid special attention to ensuring the driver could re-establish communciations if the IRA3 was disconnected/re-connected ...
and I've confirmed it continues to work correctly (2-way) after Premise is rebooted. The primary difference is that communcations is binary and not text mode.
The IRA3 driver uses a watchdog timer to periodically 'ping' the IRA3 device (and it expects a response within a few seconds). The 'ping' (send "I", pause, send "R") must also be issued upon driver initialization (OnChangeOnInit) to establish proper communciations with the IRA3.
Here are the relevant lines of code:
ClassConstructor
Code:
' Configure serial communication parameters
this.Baud = "9600"
this.Parity = "None"
this.StopBits = 0
this.CTS = false
this.DSR = false
this.RxMode = false
' Create a Serial Command object to transmit data to the M1
set oTmp = this.CreateObject("sys://Schema/Device/Serial/Command","OutCommand")
' Hide the Serial Command object
oTmp.SetValue "Flags", 2
' Communications are in binary mode so do not append CR or LF
oTmp.AppendCR = false
oTmp.AppendLF = false
' Pause between transmitted commands (milliseconds)
oTmp.WaitTime = 200
OnChangeOnInit
Code:
this.RxPurgeAll = true ' Purge the receive buffers
this.RxNextLine = true ' May not be necessary for binary communications
this.PollIRA ' Query the IRA device
I also monitor the serial port's state using
OnChangePortStatus. A serial port can have four states:
- Opening
- Opened
- Closing
- Closed
The IRA3 driver is only interested in the
Opened and
Closed states (create/delete watchdog timers).
OnChangePortStatus
Code:
if InStr(1, sysevent.newVal, "Opened", 1) then
this.CreatePollingTimer
elseif InStr(1, sysevent.newVal, "Closed", 1) then
this.DeleteTimeOutTimer
this.DeletePollingTimer
end if
