Premise Serial Communications Issue

[etc6849]

Every 5 seconds I'm sending the time and weather to an advertising sign using a serial interface. It works great until after 2500-4000 sends then the connection just quits working.

The port is still shown as open and the "worker" object I made is still acting like it's sending out the commands. Except, port spy and the sign act as if nothing is sent out.

What is interesting is if I delete the connected port by highlighting it under the device property under custom devices, then re-add it, the sign starts working again for another 2500-4000 sends.

Is there a way to force a reset on a port through code? Or is there a way to automate this deletion/re-adding of a port?

 

[123]

... Is there a way to force a reset on a port through code? ...

Resetting the port is a kludge; the cause of the connection loss ought to be corrected. But, sometimes a kludge is the most expedient means of "correcting" a problem ... so here's how to autoreset a Network port.

The attached file contains a simple device driver called "SerialWidget". Import the XDO file and create a new SerialWidget (Devices > CustomDevices > SerialWidget). Click SerialWidget's "ResetPort" property and it will connect the "Network" property to COM1. Click "ResetPort" again and it will disconnect from COM1, wait three seconds, then automatically reconnect to COM1.

The TogglePort method looks like this:

if not Devices.CustomDevices.SerialWidget.Network is nothing then
	' Disconnect the port
	set Devices.CustomDevices.SerialWidget.Network = nothing
	
	' Wait three seconds then reconnect the port
	system.addTimer 3, "this.TogglePort", 1, "TogglePortTimer_" & this.ObjectID
else
	' Connect the port
	set Devices.CustomDevices.SerialWidget.Network = Devices.SerialPorts.COM1
end if

Examine SerialWidget and copy the relevant parts to your advertising sign's Module (i.e. the "ResetPort" property and "TogglePort" method). Make the "ResetPort" property Hidden (no need to see it in the UI) and trigger it when necessary ... either after every 2000 transmissions or simply use a Timer that triggers "ResetPort" every 30 minutes or so.

Good luck!

 

[etc6849]

Thanks 123. I wish I new the reason why, but I'm stumped. I tried resetting all of the serial port properties and I've tried others valid settings from the adaptive protocol manual and nothing fixes the issue. I've also tried different serial ports and double checked the wiring. The issue happens with both Betabrite signs I have so I'll be interested in hearing how yours works if you send repetitive commands (whenever you get around to it don't rush on my part).

The sign works great though under normal use though and the driver you helped me with looks solid to me. I believe it's a Premise issue at this point, but I've got to believe the serial communications class works fine so I'm stumped. I'd think there would not be a limit on the number of repeat serial commands hidden inside the serial class, but maybe there is?

This leaves me thinking there is something in the adaptive protocol I have missed such as a requirement to reset the serial ports register etc, but I looked again and didn't see any requirements specified we weren't meeting with the driver you posted.
There is a way to reset the serial register. I tried it before and it didn't fix the problem, but I'll give that another try.

... Is there a way to force a reset on a port through code? ...

Resetting the port is a kludge; the cause of the connection loss ought to be corrected. But, sometimes a kludge is the most expedient means of "correcting" a problem ... so here's how to autoreset a Network port.

The attached file contains a simple device driver called "SerialWidget". Import the XDO file and create a new SerialWidget (Devices > CustomDevices > SerialWidget). Click SerialWidget's "ResetPort" property and it will connect the "Network" property to COM1. Click "ResetPort" again and it will disconnect from COM1, wait three seconds, then automatically reconnect to COM1.

The TogglePort method looks like this:

if not Devices.CustomDevices.SerialWidget.Network is nothing then
	' Disconnect the port
	set Devices.CustomDevices.SerialWidget.Network = nothing
	
	' Wait three seconds then reconnect the port
	system.addTimer 3, "this.TogglePort", 1, "TogglePortTimer_" & this.ObjectID
else
	' Connect the port
	set Devices.CustomDevices.SerialWidget.Network = Devices.SerialPorts.COM1
end if

Examine SerialWidget and copy the relevant parts to your advertising sign's Module (i.e. the "ResetPort" property and "TogglePort" method). Make the "ResetPort" property Hidden (no need to see it in the UI) and trigger it when necessary ... either after every 2000 transmissions or simply use a Timer that triggers "ResetPort" every 30 minutes or so.

Good luck!

 

[etc6849]

Thanks again 123. Neat example! I think I understand everything except for the following:

1. you have checked both persistent and momentary under ResetPort's class property. I was thinking these were opposite of one another (ie something momentary can't really be persistent).

2. You inherit from the transport class. I was thinking this is not necessary since the serialDevice class already does this.

 

[123]

If a Boolean property is Momentary, it means its native state is False and it can be set to True momentarily. It is often used to trigger the execution of a method or function. It works like an "OK" button on a form.

Persistent means the property's value is retained, or persists, after Premise Server is restarted. Fact is, if a Boolean is Momentary, flagging it Persistent is useless because its state is normally False (True only momentarily) so there's not much need to keep track of its state. Most properties are flagged Persistent by default and I don't bother to disable it.

Regarding the Transport class, you're right. I lifted that out of another Module where I had been experimenting with the classes.

 

[etc6849]

Persistent makes more sense now thanks. I'm guessing from most of your advice you are a programmer or computer engineer for living. Sometimes I wish I was!

If a Boolean property is Momentary, it means its native state is False and it can be set to True momentarily. It is often used to trigger the execution of a method or function. It works like an "OK" button on a form.

Persistent means the property's value is retained, or persists, after Premise Server is restarted. Fact is, if a Boolean is Momentary, flagging it Persistent is useless because its state is normally False (True only momentarily) so there's not much need to keep track of its state. Most properties are flagged Persistent by default and I don't bother to disable it.

Regarding the Transport class, you're right. I lifted that out of another Module where I had been experimenting with the classes.

 

[chucklyons]

Two points -

a) mSense is the acronym for 'More Sense' :rofl:
b ) 123 is beyond a mere programmer and/or computer engineer ray: