Premise Port Tester Beta

[etc6849]

Background:
I've made a custom driver for the specific purpose of debugging a non-responsive serial port.

123 and I are having a similar issue where our serial ports become unresponsive. The issue seems to be random, but only appears on my system if I send large amounts of data or have short polling cycles and only on custom drivers and not native drivers.

I'm completely lost as to what is causing this. I believe the only way to test my sanity and ensure my serial port is working with SYS is to use a RS232 DB9 loopback connector in combination with a simple custom driver that will record job failures.

Thus far, I have built the connector and tested this driver on an XP SP2 laptop. My plan is to test the driver on SYS installations on Windows 7, XP x64 SP2 and XP SP1 to see if serial ports work the same on each OS.

I'm hoping I can get a few Premise veterans to run this on one of their serial ports and report the results. I'm willing to make a few more serial loopback connectors and ship them out to those that PM me your address, but you have to promise to post all event details including your OS version, serial port type and brand. :rockon:

Custom Driver Details:
The driver was created from the "Other Serial Device" option in the custom driver wizard.

PollingInterval is the polling interval in milliseconds.

SendText is the text that is sent to test the port. The driver also looks for receipt of this string.

TotalReceivedJobs if something was received on the port this is incremented. If the expected test string is also received, TotalSuccReceivedJobs is incremented.

ConsecutiveResentJobs is the number of jobs that have been consecutively resent. This property is necessary because if the test string is not sent properly (for whatever reason, could be due to an error), no string will be received. This would cause the polling cycle not to be reset eventhough the port itself may still be responsive.

PollTimeOut is a watchdog timer that will toggle an interface failure if it is not removed after successful receipt of the test string. It uses the PollTimeOut property value which is in seconds, default is 10 seconds. During a fault, this gives RetryTimer (see below) one try for resending the command. If resending the command still does not result in data receipt, a PollTimeOut would occur. One can test PollTimeOut and RetryTimer by deleting a port while polling is enabled.

RetryTimer is set upon receipt of any data via the OnChangeTotalReceivedJobs script. RetryTimers purpose is to protect from instances where the port is still working and a bad packet was sent (thus nothing will be received). In this case, the port has not yet failed and deserves another chance to work. The retryTimer duration is equal to half the PollTimeOut value.

OnChangeInterfaceFailure sets an event notification. The port is not reset automatically in this version.

The driver works using a first out first in method. Most of the program flow is found under OnChangeOnNewData. If the port becomes unresponsive, an event is set recording all the needed information to aid in debugging the issue: start time, error time, job counts etc...

if sysevent.newVal = true then
	for iCnt = 0 to this.RxLinesRemaining
		if this.PollingInterval <> 0 then
			if this.RxTextLine = this.SendText then
				system.removeTimer "PollTimeOut"
				this.TotalSuccReceivedJobs = this.TotalSuccReceivedJobs + 1
				this.ConsecutiveResentJobs = 0
			end if
		end if
		system.addTimer this.PollingInterval/1000,"on error resume next: this.Send = true",1,"PollTimer"
		this.TotalReceivedJobs = this.TotalReceivedJobs + 1
		this.RxNextLine = true
	next
end if

 

[gatchel]

While I am not a premise user I have also tested serial ports by simply using Hyperterminal and the tip of a ball point pen or paperclip across pins 2 & 3 for tests with no flow control.

 

[123]

...using Hyperterminal and the tip of a ball point pen or paperclip ...

gatchel = MacGyver

 

[etc6849]

Results from a run on a XP SP2 laptop using an onboard COM port. The port did not become unresponsive and is still running.

 

[etc6849]

Results from an XP Pro X64 SP2 mini-ITX server using a Digi Edgeport (USB to 8 serial ports). As you can see from the results, the Digi is a much more reliable COM port compared to the laptop. No unresponsive port issue here either.

 

[etc6849]

AddTimer is not accurate in terms of milliseconds (such as 500ms). This is because addTimer is only accurate if the value passed is in integers of seconds (I remember 123 teaching me this at some point). However, since addTimer is called only after a successful result is received, PollInterval should not have that big of impact. This is probably why 500ms worked well on the trials I ran up until the GC100 test below...

When I sent an identical command (with the same parameters as the other trials) to a GC100 serial port, the port became unresponsive! The fix was to ensure polling time was 1 second or more (as shown in the attached jpeg). This greatly slows down the trial, but the results are better with no unresponsive port (yet). However, the error rate seems high on the GC100. For baud rate I used 9600bps. Perhaps a slower baud rate would mean less errors.

Does this mean repetitive commands sent over the GC100 may cause the GC100's serial port to become unresponsive? You'd need a lot of repetitive commands to freeze the port, but it seems like this is possible, especially since the failure time is random. In the GC100's defense, it would seem that some of this could be due to my router. See unresponsive trials below. I'm really hoping someone else can test their GC100 now!

Trials for the GC100 with PollInterval set to 500ms:
Port unresponsive.
Total jobs sent: 1649
Total jobs received: 1647
Total successful jobs received: 1647
Total jobs resent: 8
Started: 2/1/2010 7:05:49 PM
Failed: 2/1/2010 7:10:14 PM

Port unresponsive.
Total jobs sent: 6546
Total jobs received: 6544
Total successful jobs received: 6544
Total jobs resent: 30
Started: 2/1/2010 7:13:56 PM
Failed: 2/1/2010 7:28:21 PM