You can get an error message from CmdTwain that says, "Couldn’t scan image." It isn’t a very helpful message, sorry, but that’s because it is one of those error messages that should never happen.
It is like x>10 and x<3 at the same time. It can never happen. In practice though, sometimes these things do happen. (Even the x>10 and x<3 example. Computers do things one step at a time so it is possible that x>10 then something changes x and the computer checks and finds that, now, x<3. Programmers avoid doing anything that might cause that sort of thing mainly because those sorts of program are a nightmare to debug.) In most cases "this can never happen" errors happen because of faulty assumptions on the programmer’s part.
In CmdTwain, the "couldn’t scan image" error gets displayed after a document scanner has been asked to scan a page and it responds with nothing. That’s really "nothing" – not even a blank page. Internally, CmdTwain does a TWAIN_WaitForDefaultXfer() function and that should return a set of pixels. They could be black or white ones, shades of gray, colors. There might be 1, 2, 8, 24 or 32 bits per pixel. It doesn’t matter what sorts of pixels the scanner provides or how many there are; but there should be some. At this stage in the process it doesn’t even matter whether you want a PDF output, a JPEG output or just a bitmap file. All it needs is some, any, pixels.
CmdTwain is not even asking for any sort of fancy style of data transfer from the scanner. It’s waiting for the default type of transfer ("xfer" being short for transfer). It is saying, give me what you’ve got, however you’ve got it. The assumption here is that something that scans pages will scan pages and so you’ll get some dots (pixels). It is a reasonable assumption. BUT, it might not be true. You get "couldn’t scan image" if it isn’t true.
Potential reasons that asking a scanner for a scan doesn’t give any pixels at all are:
- it isn’t connected
- it isn’t turned on
- it isn’t a TWAIN scanner
- it doesn’t support a default transfer mechanism
- it has been configured to not do default transfers, or to do some specialised method instead
- it has been configured to scan a size of 0 pixels (or less)
- it might have a setting that refuses to provide a scan if it doesn’t detect anything to scan
Connected and On
The first two are obvious and most of us will check those because they’re often the fastest way to get going again. Before CmdTwain does the TWAIN_WaitForDefaultXfer(), it first tries to connect to a TWAIN Source Manager (which comes with Windows), connects to the Default TWAIN source, and tells the default TWAIN source to do a native transfer (which is why it then waits for one). If the Source Manager can’t be found, it stops and reports "TWAIN unavailable". If it can’t access the default TWAIN source it stops and says, "Couldn’t open TWAIN device. Check cables." An assumption there is that opening the source will involve trying to talk to the physical scanner and that it won’t open if it isn’t connected and switched on. That has been the case with scanners I have used; but I haven’t used every available scanner. It is possible that CmdTwain will pass that stage with the scanner not connected and/or not switched on.
After passing the "check cables" stage, it immediately does a TWAIN_SetXferMech(TWSX_NATIVE) action. This tells the scanner to do all transfers in "native" mode. Native mode is the oldest, most inherent mode available. It should be available to every scanner. The TWAIN specification (Ver 2.3, Modes Available for Data Transfer, Native) says "Every Source must support this transfer mode. It is the default mode …." It goes on to say (Section 10) that ICAP_XFERMECH, used to do the TWAIN_SetXferMech(TWSX_NATIVE) action, was introduced in TWAIN version 1.0. If the scanner is connected and powered up, it should accept the "native" command. If, even though it should, it doesn’t accept the "native" command then it ought to be in this default mode anyway. This is why getting a "couldn’t scan image" message should never occur.
Too Many Pixels
It isn’t in the list above but reading the specification does show up another possible cause – scanning too many pixels. When the TWAIN specification was initially released (1992), Windows 3.1 had yet to be released and many computers were limited to 640KB of memory. That’s not gigabytes and not even megabytes. It is less than one megabyte. The TWAIN specification states that the native transfer could fail if there isn’t enough memory available to fit all of the pixels. That made sense back then but it is less likely today. Computers have a lot more memory. It isn’t an issue that can be totally ruled out though. Scanners also scan at much higher resolutions and large format scanners are common in businesses. An A3 scan is 29.7cm x 42.0cm. That is about 11.7" x 16.5". At 1200 dots per inch, you’d have about 12 x 1200 x 16 x 1200 = 276 megapixels. If they are 32bit truecolor pixels, you need 1GB of memory to store the scanned page.
If you are getting "couldn’t scan image" from CmdTwain and you’ve tried everything else here, try reducing the size of the scan or reducing the resolution (DPI setting).
Not a TWAIN Scanner
Unfortunately, this is possible.
Historically, TWAIN was set up because lots of competing manufacturers created lots of competing scanners that used, in many cases, a different propriety standard every time. Manufacturers were noticing that very few people were buying their scanners. People weren’t buying because they couldn’t get them to work. They wouldn’t work because developers couldn’t keep up with all of the different ways they had to control all of the different scanners. As far as programs-for-scanners and scanners went, it looked like "Never the twain shall meet" (a phrase from Kipling meaning so dissimilar they cannot possibly be connected). The TWAIN working group was established to find some common ground and, in the interests of all, soon after that the TWAIN standard was released.
It is very unlikely that your scanner dates from the original times of chaos. However, standards can impede innovation so standards can, preferrably, get updates or, in some cases, get dropped or ignored. These days (2017), scanner drivers for Windows can often be installed as TWAIN drivers or as Windows Imaging Architecture (WIA) drivers. The WIA idea is said to be "newer and better" and the intent seems to be (mostly) "backwardly compatible" with TWAIN or with support for TWAIN. That said, I have seen some differences which have caused problems.
If you have the ability to uninstall and reinstall your scanner driver, it would be worth checking if installing with TWAIN ticked instead of WIA solves the problem.
Not Doing Default Transfers
A scanner is always supposed to be able to do the default transfer mode. That said, it is possible that there are some user settings in software provided with the scanner, or via physical buttons that allow the user to turn that off or to pick a different method. I’m thinking of options to scan, for example photos, directly into Windows Explorer or to a folder such as "My Pictures" or the later equivalent.
If you have used a mode like this you’ll know about it. Feel free to continue using it, but please turn if off again when you finish with it or before you use CmdTwain to do ordinary scans.
If you haven’t used it, it might be present and on by default. It might have been an option when you installed your scanner and it got ticked in the "express" install choice. You’ll have to read through your manual to see if your scanner comes with this. Manufacturers will usually list it as a feature (which it is when used as intended). If you’ve got it then you’ll need to learn how to turn it on and off.
Scanning Zero Pixels or Less
If you use the CmdTwain "WH" or "XYWH" options you can specify a scan size. Many scanners also have settings that allow you to change the scan size. In theory, you could set a scan size of zero or, with scanner provided software or buttons, even a negative one.
Try doing a default (A4 sized) scan with CmdTwain without WH or XYWH. That might suggest the problem is in how well (or poorly) I’ve explained those options.
You could also try resetting any scanner defaults. That should restore a normal sized scan.
Nothing to Scan so No Scan
This might be a feature for some scanners. It sounds reasonable.
If this is the case, the solution would be to check that there is paper to scan in the document feeder and that the feeder is working. Some feeders have separate power switches and some have power cords that can come out.
The sensor might require a certain brightness or level of opaqueness or pattern to detect the paper. It might be possible to change that (sorry – you’ll need to read the scanner manual again) or to turn the sensor off.
End of Scan
As another potential cause, it is possible that some scanners return an error after scanning a set of pages, in order to show that the end has been reached. This would cause a single "couldn’t scan image" message to appear at the end of a set of scans.
I may include a change to address that in a future release.
