Home › Forums › TWAIN Classic › Kodak 5200 performance (my app vs. svt) file mode transfer
- This topic has 3 replies, 2 voices, and was last updated 9 years, 11 months ago by MarkM.
- AuthorPosts
I have an issue with the twain app I’ve developed on a Kodak 5200 with dualstream (300 dpi tiff and jpeg) in file transfer mode. I have used file transfer mode on all previous Kodak models without issue but now running tests with 5200 my app is lagging behind the scanner drastically. Running a stack of 150 pages when it finishes my app could be 30 pages behind. I would think it might be something environmental but when I run svt it is usually finishing right after scanner so kind of ruled that out plus I’ve seen it on 2 different PCs and scanners. I have turned on twain debug and compared traces from svt to my app and don’t see any differences that would explain it. In my app I’ve narrowed it down to the one call that transfers the image (DG_IMAGE, DAT_IMAGEFILEXFER, MSG_GET). Logging that shows that in stack of 150 pages it averages 16-30 msec but then has occasional 200-900 msec times. There reailly aren’t many calls going on during capture loop (DAT_IMAGEINFO, DAT_EXTIMAGEINFO, DAT_SETUPFILEXFER, DAT_IMAGEFILEXFER) so have to believe either some capability svt has set before scanning is difference or the difference is the svt application itself (threading, priority, no mfc) but I have tried number of things and always get the same result.
When my app is in native mode transfer I do have seperate thread to compress and write images to disk but I don’t see how it is possible to do that in file mode. File mode is how I have always gotten the rated performance out of high speed Kodak scanners. My app is an MFC app with it’s own background thread for twain.
I can post more info or code or debug logs but just wanted to see if anyone else had experienced similar problem.
Regards
There are a number of things to watch out for:
– make sure that the c:programdatakds_kodak folder is excluded by any virus protection software
– make sure that any folders receiving image files are also excluded
– check that debug=0 inside of c:programdatakds_kodakkds_i5000twainconst.ini (no such file is okay too)
– make sure that image compression is on for your application
– are the image files created locally or on a network drive?
– make sure when running SVT that files are saved to disk, so the test is fairAfter doing all of that, if the problem persists, then edit c:programdatakds_kodakkds_i5000twainconst.ini, and make sure the following is in there:
[dsidentity]
debug=1
logbackup=-1Delete any log.* folders inside of c:programdatakds_kodakkds_i5000twain
Run one scan session with SVT, and then run one scan session with the application. About twenty sheets of paper should be sufficient.
Turn off the scanner, zip up the contents of the c:programdatakds_kodakkds_i5000 folder, and attach them to a reply in this thread. Don’t forget to undo the logbackup and debug changes inside of const.ini
Thanks for the suggestions. Everything was local and compression was turned on. Virus scan is running but tried it with it turned off and no difference plus svt was not having problems with it on anyway.
Well, I think I found my problem. And the solution was to change my initTwain routine to load TwainDSM.dll instead of twain_32.dll. I’ve had my app for ages and the twain_32 had been there forever.
When I first ran the Twain_MFC_App from twain.org I thought it had the same problem with lag but then I moved the mouse over the dialog while it was running and then it was working fine. I’m assuming there is something going on with the cdialog message pump and the twain callbacks and the mouse move kicked the idle processing and got things going. I changed sample app to use message and not callback and that solved the problem. After looking for some differences between it and my app I noticed the different dll loading. I switched mine and it’s runs in file mode and keeps up perfectly.
Just curious if anyone could explain why that makes such a difference.
Thanks in advance.
Congrats on the fix…
Unfortunately, we don’t have the latest TWAIN_32.DLL source code modifications made by Microsoft (which is ironic, since technically it belongs to the TWAIN Working Group). We know that there have been alterations over time, because the size of the binary has changed.
Going with TWAINDSM.DLL is perfectly justified. It’s 100% compatible with the older code, and you have access to its source code (http://sourceforge.net/projects/twain-dsm/). I know from my own testing that there is a profound performance difference during capability negotiation (about 5-to-1), so I can’t say that I’m surprised that there’s an issue with image transfers, but this is the first that I’ve heard of that particular problem.
- AuthorPosts