XaP xapmcsTemp0X .net 2.0 Version

[Pete]

No changes with updated version. Runs for a bit then quits. Com shows reads are fine. Just noticing that main GUI variables don't update / broadcast xap after a period of time. To me it looks more like the xap stops and the RS-232 keeps going; but that's only from watching the 3 gui's (xaptemp0x, xaptemp0x comm and xaptemp0x messages). (IE: no updates of variables on main page gui, continued RS-232 comm and no new messages in a couple of days).

Next - testing today - deleted all ini/txt files - started from scratch - its been about 2 hours and everything looks good. GUI is being updated. xap broadcasts. I probably should have done that earlier.

[Michael McSharry]

Just noticing that main GUI variables don't update

I'm assuming the "main GUI" is the browser for xapmcsTemp0x. This indicates that changes in values reported from the RS-232 are not being observed. This however, is in conflict with the "FormatAnalog" from the debug which is executed as the value change is executed. Are you certain the xapmcsTemp08 browser is not being updated?

With the attached I added the mechanism to enable the socket level debug output. It will go into a .txt folder in \Data\xapmcsTemp0x. It is enabled by editing xapmcsTemp0x.ini to add a line near the DebugLog= line that contains
TCPDebug=1
After adding this line xapmcsTemp0x can be started.

This will show all the xap (and HTTP) traffic being processed.

[Pete]

I'm assuming the "main GUI" is the browser for xapmcsTemp0x.

Yes

Are you certain the xapmcsTemp08 browser is not being updated?

Yes unless its bringing up a cached page when I hit refresh - times of variable changes were from about 1.5 hours ago.

Typing on the computer that I am using to test. After deleting all saved "txt" and "ini" files and reconfiguring it earlier today; the application did quit again about 1 hour ago or so. I was going to try a direct serial connection instead of the QSE-100; but would rather try the new updated xapmcsTemp0x you just posted. (easier than running a new serial cable)

Thank you Michael.

[Michael McSharry]

If the Comm window continues to show Temp08 traffic then the Quatech should not be the issue. Both debug files can contain information of interest. The TCP/Socket debug will become large.

[Pete]

Still running at this time 1454C. Txt file at 1.7 Mb. (compressed it will be much smaller) I was going to wait until it froze again to stop running application. Thanks for having a look / enabling granular debug.

[Pete]

It quit around 1500c or so. I've attached both logs.

Thanks Michael.

[Michael McSharry]

This confirms that the xAP interface is working fine, but the RS-232 data reception had stopped. The TCP debug ini setting can be removed as this is not the source of the problem. If you want to pursue further with the Quatech I have added additional trace information on the RS-232 socket with the attached.

Note below from your general debug file. There was about 1 minute between reception of sensor #3 to sensor #4. After that there was no more data received. The Temp08 is likely pumping out the sensor data every second so something happened between the Temp08 and the PC handling of received data.

False 5/2/2010 3:03:43 PM | 5/2/2010 3:03:43 PM | xapmcsTemp0x Temp05 Data: > 
False 5/2/2010 3:03:44 PM | 5/2/2010 3:03:44 PM | xapmcsTemp0x Temp05 Data: TUE 18:23:59 
False 5/2/2010 3:03:45 PM | 5/2/2010 3:03:45 PM | xapmcsTemp0x Temp05 Data: Reading Sensors... 
False 5/2/2010 3:03:45 PM | 5/2/2010 3:03:45 PM | xapmcsTemp0x Debug Format Analog BC0000004CE93526=0, port=COM3, accept=False, Channel=0, Type=0 
False 5/2/2010 3:03:46 PM | 5/2/2010 3:03:46 PM | xapmcsTemp0x Temp05 Data: Humidity #01[5400000075150626]=44% 
False 5/2/2010 3:03:47 PM | 5/2/2010 3:03:47 PM | xapmcsTemp0x Temp05 Data: Temp #01[84000800E947A110]=71.25F 
False 5/2/2010 3:03:47 PM | 5/2/2010 3:03:47 PM | xapmcsTemp0x Debug Format Analog 84000800E947A110=71.2, port=COM3, accept=True, Channel=0, Type=0 
False 5/2/2010 3:03:48 PM | 5/2/2010 3:03:48 PM | xapmcsTemp0x Temp05 Data: Temp #02[5400000075150626]=70.80F 
False 5/2/2010 3:03:48 PM | 5/2/2010 3:03:48 PM | xapmcsTemp0x Debug Format Analog 5400000075150626=70.8, port=COM3, accept=True, Channel=0, Type=0 
False 5/2/2010 3:03:48 PM | 5/2/2010 3:03:48 PM | xapmcsTemp0x Temp05 Data: Temp #03[7F0000025F611528]=72.60F 
False 5/2/2010 3:03:48 PM | 5/2/2010 3:03:48 PM | xapmcsTemp0x Debug Format Analog 7F0000025F611528=72.6, port=COM3, accept=True, Channel=0, Type=0 
:
:
False 5/2/2010 3:04:43 PM | 5/2/2010 3:04:43 PM | xapmcsTemp0x Temp05 Data: Temp #04[BC0000004CE93526]=72.37F 
False 5/2/2010 3:04:43 PM | 5/2/2010 3:04:43 PM | xapmcsTemp0x Temp05 Data: > 
False 5/2/2010 3:04:45 PM | 5/2/2010 3:04:45 PM | xapmcsTemp0x Temp05 Data: TUE 18:24:59

[Pete]

Thanks Michael. Yes this was a test with the Quatech QSE-100. WIll utilize your newest application and pursue with Quatech.

Actually just noticed that I can see the Quatech device on the network but the web interface doesn't come up.

[zap]

Pete,

Check the firmware on the QSE-100, I was having frequent drop out with the DS9097U updated to the lastest firmware no more drop outs.

[Pete]

Yes - just updated firmware to 4.26 from 4.01.

Another "issue" I found was a "fat finger typo" of my gateway address off by one digit in the second octet. I can't believe I didn't notice this before.

Interesting; I've changed it twice now and it keeps changing back to the wrong second octet.

After third time it worked.

Thanks Zap - it should work now.

[Pete]

After a "few" hours its working fine. So the firmware fixed it!

Thank you Michael and MW.

Still working fine overnight. Thanks again guys.