Serial port too persistent won't go away!

General
1

I have an app that interfaces with a simple serial scale device. I can connect and it works perfectly, however when the cable is taken out and restored I’m unable to deconstruct the previous instance. The code below is my ‘Setup’ routine, which executes perfectly when it first runs, but doesn’t work on consecutive executions. Setting the Serial to nil ‘seems’ to work, in that it throws NilObject exceptions when I test it, but there seems to be some kind of residual connection lingering that doesn’t let me Setup the Serial again until I terminate and re-launch the app. Is there some secret to getting the System.SerialPort(x) to release it’s resources?

[code]if ScaleSerial <> nil then
RemoveHandler ScaleSerial.DataAvailable, AddressOf ScaleSerialDataAvailable
ScaleSerial.Close
ScaleSerial = nil
end if

ScaleSerial = new Serial
ScaleSerial.Baud = serial.Baud9600
ScaleSerial.Bits = serial.Bits8
ScaleSerial.Parity = serial.ParityNone
ScaleSerial.Stop = serial.StopBits1
ScaleSerial.XON = false
ScaleSerial.CTS = false
ScaleSerial.DTR = false

AddHandler ScaleSerial.DataAvailable, AddressOf ScaleSerialDataAvailable

// read-in Config file…

ConfigDictionary = New Dictionary
ReadConfigValues

// try attaching to Serial port…

AutoSerialPortSelection(0)[/code]

2

Maybe placing the serial port as a property of a ContainerControl could help. When you close the container control it should destroy the property, so when you instanciate a new containerControl you start again with a brand new property.

It would work with a window as well.

3

For portability I’m putting all this code in a Module, with the intent of moving it between many projects - so without any Windows to hold a ContainerControl.

I’m currently holding the ScaleSerial property in the Module, and calling “ScaleSerial = new Serial” after setting it to Nil in a previous line. It would seem that setting that property to Nil, and calling a New object instantiation on it would wipe it clean - it sure feels like I should be trying to nest the ScaleSerial property in another control like you suggested.

4

Try a .Flush just after your if to make sure everything is cleared out for the close and nul

5

Gave this a shot, and same bad results :frowning:

Should there be any reason to call a lower-level (hardware) function of any kind, not that I know what that would be…

if ScaleSerial <> nil then ScaleSerial.Flush RemoveHandler ScaleSerial.DataAvailable, AddressOf ScaleSerialDataAvailable ScaleSerial.Close ScaleSerial = nil end if

6

Have you tried it in a really simple project with a single flow ie. dim, open, send/receive, close, nil then repeat the same process once more with copy + paste code? Doing this would shed a little more light on where the problem might be, it might be a a code design issue, a xojo framework issue or a serial driver problem. Does it only happen when you have received some data or sent some data? Does it happen if the comms cable is unplugged?

Just a few thoughts for you to try out.

8

Which OS are you using?

9

System 10.11.6 El Capitan

10

Ugh! It was my coding error (of course).

Bottomline: I use the content of a string returned from the Serial buffer to determine if I’m attached to the right device, and after evaluating it successfully I neglected to set it to reset it, thus resetting the port appeared to not work, when in fact the code was misbehaving perfectly. Thanks for your help!

[code] // sending “@” in previous call should return a string similar to this…
'I4 A “B434947054”

	if InStr(AutoPortSniffingPacket, "I4 A") > 0 then
			AutoPortSniffingPacket = ""
			Return
	End if  
	
	
	// go past here if need to continue trying the next port and if "I4 A" wasn't found in the buffer
	
	MT_SICS.ScaleSerial.Close
	AutoPortSniffingPacket = ""
	AutoSerialPortSelection(LastPortNumberAttempted +1)[/code]