I use the native CM11A and MR26A drivers. The CM11A is connected to the PC's single serial port. The MR26A is connected to one of the serial ports of an Edgeport/8. These two drivers continue to work correctly after Premise Server is restarted. Mind you, these are native drivers (C++) developed by the Premise team.
I have an ELK M1 driver (a Module) ... its design is probably similar to your Onkyo driver.
OnChangeOnNewData monitors the
RxTextLine buffer for incoming data.
OnChangeOnInit contains only two lines:
Code:
'OnChangeInit is used for any device or COM port initialization code
this.RxPurgeAll = true ' purges the receive buffers
this.RxNextLine = true ' requests the next line of data from the serial port
ClassConstructor contains all of the serial-port configuration code:
Code:
dim oTmp
' 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
' Append carriage-return and line-feed to all transmitted data
oTmp.AppendCR = true
oTmp.AppendLF = true
' Pause between transmitted commands (milliseconds)
oTmp.WaitTime = 100
' Configure serial communication parameters
this.Baud = "115200"
this.Parity = "None"
this.StopBits = 0
this.RTS = "Disable"
this.DTR = "Disable"
this.CTS = false
this.DSR = false
I guess setting the serial-port parameters (Baud, Parity, etc) could be done in
OnChangeOnInit to ensure it happens each time the driver is initialized ... but it has not proven to be necessary in my situation.
FWIW, the PC and the ELK M1 are connected via Ethernet (and not hard-wired via their respective serial ports). I use the Lantronix UDS10 driver as a "shim" so that the M1 driver can speak TCP/IP. All of this is transparent to the M1 driver and it assumes it is speaking via a serial port.
BETA 1 of the ELK M1 driver would suffer after the Premise Server was restarted. Restarting would (naturally) interrupt the connection and garble any received packets. In BETA 2, I made the packet-validation function more robust so that it would reject truly mangled packets. This may have no bearing on your situation but just to highlight the fact that problems are exposed when the testing 'gets medieval' (reboots, devices unplugged, garbled packets, momentary power outages, etc).