Developer Portal | MC75 -- Scan buffer question

Submitted by Marcus Kurath on August 4, 2009 - 7:18pm

Tags:

I have a customer who needs to scan several hundred items at a single delivery site with an imager. The problem is that after a few scans the device seems to need to "catch up" and remains locked with the hour glass on the screen until it can process the scans. They can then resume scanning until the buffer once again gets full and locks the device while it processes it. The customer is using the scan API in the SDK and not data wedge

Intermec CN3 does not display this behavior and seems to allow continuous scanning

Any Suggestions??

May 4, 2019 - 9:29am

Alan Epshteyn

Do you know if their

Do you know if their application is multithreaded? More specifically, are they submitting reads on one thread and processing them in another? Or do they have a single loop where they submit & process a read on a single thread?

Vote:

May 4, 2019 - 9:29am

Marcus Kurath

I dont know if it is single

I dont know if it is single or multithreaded...It sounds like you would recommend multithread....I'll check into this

Thanks

Vote:

May 4, 2019 - 9:29am

Christopher Sather

Marc, look at the persistent

Marc, look at the persistent memory techniques in this post and see if
it helps. It may help if the developer used bigger buffers and wrote
to the suggested flash.

https://devcentral.symbol.com/shwmessage.aspx?forumid=52&messageid=703

Vote:

May 4, 2019 - 9:29am

Chin Fatt SEK

May be is worth try disable

May be is worth try disable the word completion option from Start ->Settings ->Personal ->Input -> Word Completion.

Vote:

May 4, 2019 - 9:29am

Juan-Antonio Ma...

What does the application do

What does the application do with scanned data? Just store them -somewhere- or do some processing (search in local DB, for instance)?
I have often seen this behaviour (eternal hourglass) on some customer/3rd-party applications... and -as usual- they complained about our stuff.
Eventually -in most cases- it was because of wrong non-optimised whatsoever processing.
Sometimes it was because of slow memory access... but this is history now ... is this not?

Vote:

May 4, 2019 - 9:29am

Anonymous (not verified)

Not seeing the customer

Not seeing the customer source, there's really no way to tell if it's a problem with the application or our scanners. That's were my group can help.

If you'd like some formal assistance with this, contact Luke Petrozza (my Manager). Our group is part of ECRT and is chartered with performing Applications Support for Customers. One of the tasks that we can help with is to look at the customer's code and suggest improvements.

If it turns out to be a scanner problem, we'll create the SPR and help track it.

Vote:

May 4, 2019 - 9:29am

Jarod Fox

Is the application written

Is the application written using managed code or native code?
Is the scanner opened/closed (or if managed a new instance created) each time a scan is processed?

The symptoms really sound like the CF garabage collector, but as Dave points out without additional information is difficult to diagonse.

Vote:

May 4, 2019 - 9:29am

Doug Petito

For what it is worth the word

For what it is worth the word completion setting was the root cause of a similar issue found on the VC6096 WM6.1 and replicated on the MC75. Turning it of f solved the problem with that customer.

Vote:

May 4, 2019 - 9:29am

Prashanth Kadur

Marc, Is this a .NET

Marc,

Is this a .NET application?

As some one on this thread has mentioned, you will have to handle this situation with multiple threads. If this is a .NET application, I may be able provide you a sample application that shows you how to accomplish this.

Vote:

May 4, 2019 - 9:29am

#10

Marcus Kurath

The application is written in

The application is written in C++

Mike Holman is working to have a con call with ECRT and the ISV..

thanks for everyones feedback

Vote:

May 4, 2019 - 9:29am

#11

Juan-Antonio Ma...

I am afraid I missed an

I am afraid I missed an important point:
Intermec CN3 does work fine.
Obviously not using the same application.

Intermec can either use their APIs, either use an "embedded" factory-installed "datawedge" of their own.
Which way are they using the imager on CN3?

On the other hand, does this lock-up happen after a few scans despite the rate of readings (i.e, how fast they read barcodes)?
Do they initialise the imager (including SCAN_AllocateBuffer), then loop on scanning all the barcodes, and when done, close the imager (so SCAN_DeallocateBuffer)?
Or do they instead init->read one->close for every barcode?

Vote:

May 4, 2019 - 9:29am

#12

Marcus Kurath

Obviously not using the same

Obviously not using the same application.---
Yes--They are running the same application--obviously with a modified API for Intermec
_____________________________________________________________________

Intermec can either use their APIs, either use an "embedded" factory-installed "datawedge" of their own.
Which way are they using the imager on CN3?---
API's

_____________________________________________________
On the other hand, does this lock-up happen after a few scans despite the rate of readings (i.e, how fast they read barcodes)?--
It is related to the rate of readings
_______________________________________________________
Do they initialise the imager (including SCAN_AllocateBuffer), then loop on scanning all the barcodes, and when done, close the imager (so SCAN_DeallocateBuffer)?
The imager is initalized at the beginning of the job and closed after all scanning is done
__________________________________________________________________
Or do they instead init->read one->close for every barcode?Obviously not using the same application.
No
__________________________________________________________________

Intermec can either use their APIs, either use an "embedded" factory-installed "datawedge" of their own.
Which way are they using the imager on CN3?

On the other hand, does this lock-up happen after a few scans despite the rate of readings (i.e, how fast they read barcodes)?
Do they initialise the imager (including SCAN_AllocateBuffer), then loop on scanning all the barcodes, and when done, close the imager (so SCAN_DeallocateBuffer)?
Or do they instead init->read one->close for every barcode?

Vote:

Search form

MC75 -- Scan buffer question