Please explain these exceptions

Please explain these exceptions

I looked through the samples for RFID and ended up implementing the
following (which would start the scanning process independently of any
hardware button push, one of my customer's requirements):

static RfidReader objReader = new RfidReader();


if (objReader.RfidTags.Count > 0)
this.Tag = objReader.RfidTags[0].Id.ToString();
this.DialogResult = DialogResult.OK;
MessageBox.Show("Timeout with no tag scanned.");
catch (Exception ex)

What I'm seeing is that it mostly works, but at times I'll see these exceptions:

Rfid Reader timed out. (Tag cannot be found in the specified time)
The Rfid Reader not responding (SetTagProtocol: Set15693Protocol failed)
The Rfid Reader not responding. (TakeInventory: 15693 TakeInventory failed)

I sorta get the first exception (although I would have expected it to
just continue on the normal flow with an empty objReader.RfidTags

The second and third exceptions mean nothing to me. Note that if these exceptions happen, they happen almost immediately after the StartScan/WaitForTag calls. I suspect it is some kind of initialization thing, but it seems odd that it is not consistent.

Anyone know what these exceptions mean and whether it is something the user is doing?

Due to customer requirements, I'm using SDK and PD v 2.0 and I can't upgrade easily.


12 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

Hi Rick

We tried the code portion provided but could not reproduce the
exceptions. Can you provide the

1. Would
it be possible for you to send us the full test code?

2. Can
you send us the MCA log file set at DEBUG level when the error has occurred?

3. Could
it be the issue is a hardware related one? Would it be possible for you test on
more than one MCA tablet just to confirm it is not a hardware issue on one



1) shortly

2) Where is the MCA log file located and how does one set it to DEBUG level? I'm doing this blind as I do not have a device -- only the customer does -- so I need non-programmer type instructions.

3) They have other devices and will try that.



1. Edit the MCA configuration file (C:\Program Files\Intel\MCA\Bin\IntelHealthcare.cfg) and set the log level to debug:

/Intel/HealthcareSDK/Logging/DefaultLevel = DEBUG

2. Delete the MCA log file (c:\temp\MCA.log). The MCA log file will be recreated automatically when the next event occurs.

3. Take the necessary steps to reproduce the failure.

4. After the failure occurs, immediatly save the MCA log file and then send it back to us. You can attach it as a file under the Options tab in your reply on the forum.

5. Edit the MCA configuration file (C:\Program Files\Intel\MCA\Bin\IntelHealthcare.cfg) and set the log level to the default level of Warnings:

/Intel/HealthcareSDK/Logging/DefaultLevel = WARN

Here you go...


Download MCA_logs.zip121.26 KB

Hi Rick

Would it be possible for you to send us the full test code?

Also, were you able to test this on more than one MCA tablet?



I don't think they've tested on multiple tablets yet.

Here's the test app. The exceptions occur with the approach under the "Scan2" button.

Note that they don't always happen -- just often enough to be annoying.



Download TestDT2.zip51.58 KB

Hi Rick,Were you able to test this on more than one MCA tablet?Thanks,Steve

Hi Rick,

development team has tried many combinations with the provided code and also
with our own custom executables, but could not reproduce the error.

while parsing through the provided logs we came across the below logs.

[2010-08-27 09:35:21.062]
{S0-P3892-T560} [RfidAPI] ::RF_StartScan(readerHandle=0x00000607) ENTERED

[2010-08-27 09:35:21.062]
{S0-P3892-T3708} [RfidAPI] ::RF_Release(readerHandle=0x00000607) ENTERED

the RF_StartScan and RF_Release functionalities have been called at the same
time (09:35:21.062)
for the same reserved device (readerHandle=0x00000607) from different
threads (Thread IDs T560 and T3708) of a single process. By using this kind of
programming logic nothing can be accomplished, rather than complicating the
device usage scenarios. Any problem or behavior will be hard to debug when
uncontrolled multi-threaded programming are performed while sharing the same
device reservation across threads. We strongly suggest that you refrain from this
programming style until it is the required business logic.

have tested these conditions as well in our testing but could not reproduce the
error reported. At this point it seems the reported issue might be
device/hardware specific on this specific tablet. As per the above, we
recommend you change the program logic and check if that helps reducing the
reproduction of erroneous scenarios.

Were you able to test this on more than
one MCA tablet?



Still no indication from my customer that they've tried on other devices. I'll let you know as soon as I do.

The threading is there because the customer requires that there be a functioning cancel button to abort the scanning timeout. Perhaps you have a better approach?

Regardless, the exceptions were happening with and without threading, so I don't think that is the cause.


ok, finally got an answer. Seems that only the one unit is acting this way.

Otherwise, normal behavior.


OK, new question about threading....

as you know, I'm using the:



This works great as far as the user is concerned because they don't have to press the hardware button to start the scanning process. Because it takes some time to position the tag, they want the WaitForTag() wait time to be 10 seconds. That all works great.

But, they also want a functioning CANCEL button because sometimes they want to quit and don't want to wait the 10 seconds.

My initial solution was to loop 10 times with a 1 second timeout, but that was unacceptable because of the 20 beeps -- indicating start scan and failed scan.

My next solution was to start up a separate thread to call StartScan/WaitForTag and then, if the cancel button is pressed, call ReleaseDevice() from the UI thread.

Are you saying I shouldn't use threading? If so, then what is the better approach? I could go back to the original approach if I could disable all the intermediate beeps somehow (they want the initial start beep and the final fail beep), but I didn't see an api to do that.


Leave a Comment

Please sign in to add a comment. Not a member? Join today