Beijer Electronics (formerly QSI Corporation)

Manufacturer of Mobile Data and Human Machine Interface Terminals.
It is currently Sun Nov 19, 2017 8:56 pm

All times are UTC - 7 hours




Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Dec 18, 2009 9:45 am 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Followup:

the unit finally failed. The last message was

Quote:
Packet from [10,0,100,79]:59202 on channel 4159


then

Code:
UDP or RAW packet Refused - no free local channel
error code -9, channel 0.

Closing Channel 0

UDP or RAW packet Refused - no free local channel
error code -9, channel 0.

Closing Channel 0


and so on...out of the EthernetError on the EthernetServerV2.

Then when I tried to use the httpClient:

Code:
About to executeGet
Get executed on 10.0.100.79:12101/blahblahblah

connection refused - no free local channel


this time conn refused came out of the httpclient's EthernetError.


Top
 Profile  
 
PostPosted: Fri Dec 18, 2009 9:50 am 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Jeremy wrote:
Lets see if the EthernetServer is getting disabled somehow, which would be the most likely cause of dropped messages. If the EthernetServer is still enabled, then there may be a serious interaction problem between the HTTPClient and the EthernetServer.


This immediately triggered in my mind and I remembered that when I do get serious errors I disable the EthernetServerV2. Is this the source of the problem?

I'm unsure as to why I added this code, but I will remove now.

Also, I am doing the same enable/disable with the httpClient, in some cases to avoid waiting for server responses. Could this also an issue?


Top
 Profile  
 
PostPosted: Fri Dec 18, 2009 9:58 am 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
Well, this appears to be an ID10T error.

After removing that line of code, the closing channel appears now just fine.

I guess the question is does a disabled EthernetServerV2 cause this problem intentionally? And does enabling/disabling an httpclient cause other possible issues as well?


Top
 Profile  
 
PostPosted: Fri Dec 18, 2009 10:05 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
Disabling the EthernetServer object, in particular when it is handling UDP will cause this problem.

Some of this is a little subtle and involves the difference between a MSG_COMM_ACCEPT and a MSG_COMM_RECEIVE. MSG_COMM_ACCEPT (the firmware message which triggers the CommAccept() call) is a directed message and will be received by the object to which it is directed regardless of whether that object is enabled or not.

MSG_COMM_RECEIVE is a registered message and will go to all objects who have registered for that message in z order. While it is rare that more than one object would handle a MSG_COMM_RECEIVE on a single communication channel, it is supported, but it also has the effect of dropping messages to disabled objects.

Unfortunately in this case, closing the connection is driven by the MSG_COMM_RECEIVE, which means that if MSG_COMM_RECEIVE is not handled the channel is not closed and freed back up.

I would have to take a bit and analyze the HTTPClient code to see what effect disabling it would have. As the connections are TCP based and the server should be terminating the connection my initial gut feeling is that it won't be as harmful.

In any case, you might consider using a global errorstate type flag instead of disabling communication object, and simply not processing communication data if the global errorstate is set.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Fri Dec 18, 2009 10:08 am 
Offline
QSI Support
QSI Support
User avatar

Joined: Wed Mar 08, 2006 12:25 pm
Posts: 881
Location: Salt Lake City, Utah
I wouldn't classify this as a bug. Both the EthernetServer object and the firmware are doing what they are designed to do. We debated exposing an enabled property for the EthernetServer object, and decided that for TCP there could be legitimate, albeit rare, reasons to do so. I don't know that we thought through the UDP case quite as well. The fact that stuff is dropped in that case is kind of an unfortunate side effect of how the overall system is designed.

In general, I try to avoid disabling communication objects myself.

_________________
Jeremy
http://www.beijerinc.com


Top
 Profile  
 
PostPosted: Fri Dec 18, 2009 10:19 am 
Offline
User avatar

Joined: Mon Apr 09, 2007 10:50 am
Posts: 48
Location: Dayton, Ohio
The code is easily changed to avoid disabling them, so I will do so. Again thanks for working through this with me even though it was user-caused.

I went back through my notes, and the reason I disabled the EthernetServer when a bad error occurred was that if I did not disable it, it would continue to receive messages and in some cases repeatedly show the error screen, often times losing track of what the initial problem was.

Down the road I added a button to avoid a forced reboot of the unit, which then led to these issues, as you'd have a normally functioning unit with a disabled EthernetServerV2.

Like I said, ID10T error... :(


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 21 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group