Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Testing the validity of a Com Port
Message
From
20/08/2008 13:49:14
 
 
To
20/08/2008 13:28:20
Timothy Bryan
Sharpline Consultants
Conroe, Texas, United States
General information
Forum:
ASP.NET
Category:
Coding, syntax and commands
Miscellaneous
Thread ID:
01340243
Message ID:
01340438
Views:
5
>>>>Hi,
>>>>>Maybe in this is my answer. My connection is via a third party product and not using the .NET SerialPort object. I suppose I could pre test the port by trying a SerialPort.Open().
>>>>
>>>>Don't think that would help. As mentioned the SerialPort.Open() should succeed whether or not the device in question is connected.
>>>>You'd probably need to use the .NET serial port to do a bit more probing to determine if the device was available but, not knowing the device, I've no suggestions as to what might be appropriate. What's the device in question?
>>>
>>>In this case it is an Rfid reader. We have been using these and other serial devices (gps, rfid, scales, cameras) but with this reader and this API I am getting this result. Part of the problem is I don't know exactly what is going on in the API where I am calling the connect into. It would be nice if it would return a fail on its own.
>>
>>Is the API specific to the hardware?
>Yes it is created by the manufacturer to use for interfacing with their device.
>
>>Do you have any information on accessing the device other than via the API?
>Yes, but it gets real complicated. I had previously started creating a generic api of my own so we could use mulitple different maufacturers of devices. I have successfully connected to this device many times and have no problem if it is fully booted up and ready to be connected to.
>
>>Maybe the API provides some other method/property which would help determine the device status?
>I just looked through the sample application they provided and the documentation and there doesn't appear to be any properties to check. It is supposed to throw a BasicReaderException but it doesn't seem to do this in all cases. I am catching this but it doesn't always seem to catch the problem.
>>
>>>Is there a way to put some kind of timeout on execution of a command?
>>
>>Don't think so - except perhaps using a seperate thread (which you seem to be considering). The problem there might be that a Thread.Abort wouldn't actually abort the thread if the wait is occurring in unmanaged code in the API :-{
>I am going to use threading, but need to use it in the wrapper class and not in the application. I don't see how it would help this problem however as you state, I can't really abort this single line of code that calls out to the reader. My code looks like this where it hangs.
>
>/// <summary>
>/// Open Reader Connection
>/// </summary>
>/// <param name="connection">connection</param>
>/// <returns>True if successfull</returns>
>private bool OpenReaderConnection(string connection)
>{
>     bool llSuccess = false;
>     string lcMessage = null;
>     BRIReader.LoggerOptionsAdv LogOption = null;
>     bool idlLogging = RfidSettings.Instance.EnableIDLLogging;
>
>     if (idlLogging)
>     {
>	//optionally create the Logger Options *****************************
>	LogOption = new BRIReader.LoggerOptionsAdv();
>	LogOption.LogFilePath = ".\\IDLReaderDebugLog.txt";
>	LogOption.ShowNonPrintableChars = true;
>	//******************************************************************
>     }
>
>     try
>     {
>	if (RfidSettings.Instance.UseDefaultBuffers)
>	{
>	     if (idlLogging && LogOption != null)
>		reader = new BRIReader(null, connection, LogOption);
>	     else
>	                     reader = new BRIReader(null, connection);  // line of code that hangs -
>	}
>	else
>                                          Blah, blah, blah
>
>
>Tim

You could try starting the OpenReaderConnection() method in a seperate thread and puttiing the main thread to sleep for a reasonable period. If the OpenReaderConnection method hasn't completed at this point then use Thread.Abort() on it's thread and ask the user to check the connection. Not very pretty though and, as already mentioned, the Abort() may not actually kill the thread.
Previous
Reply
Map
View

Click here to load this message in the networking platform