Support for ML-1660

Michael
2010-06-29
2013-10-23
1 2 > >> (Page 1 of 2)
  • Michael
    Michael
    2010-06-29

    Hello all,

    I just purchased an ML-1660 which doesn't seem to be supported by SpliX 2.0.0-2ubuntu3.  Is any effort underway to make it work, or does anyone have any experience with it?  When I select the ML-1640 driver the printer at least wakes up and pulls through a page, but doesn't print anything.  Samsung's proprietary drivers worked when I installed them in an Ubuntu VM.

    If nothing is going on here I may take a look myself when I have time.  Can anyone give me any hints for getting started?  Otherwise I will start by comparing the output of the SpliX 1640 filter to Samsung's proprietary one to see if I can spot any obvious similarities and differences.

    Regards,

    Michael

     

  • Anonymous
    2010-07-22

    Sometimes it helps to disable zlib compression when compiling splix.

     
  • Michael
    Michael
    2010-07-22

    Do you think that that is the issue?  I didn't see any indication that the printer was supported at all, which was why I was considering trying to add support myself.

     
  • Michael
    Michael
    2010-10-29

    Thanks, already done that.  I fear though that it will be a while before I get round to actually doing something here (although I hope that it won't be too complicated - perhaps some small change to Samsung's printing language).

     
  • Bas Roufs
    Bas Roufs
    2011-01-15

    Hello Everybody

    Recently, I also purchased a Samsung ML-1660 monochrome printer. I have tried the following Splix drivers in combination with CUPS: ML-1510, ML-1520, ML-1610, ML-1630, ML-1640, ML-1710. A driver for ML-1660 is not yet there.  Each driver delivers the same result: a print comment sets the printer into motion and the paper moves through it -correctly from mechanical point of view. However, each time the paper remains white: so, no prints!
    Has anybody a clue how to get real prints?
    Thanks, respectfully yours,
    Bas.

     
  • Bas Roufs
    Bas Roufs
    2011-01-15

    Hello everybody

    An attempt to print a 'self test page' ends up in the following comment:

    Print Self-Test Page Samsung_ML-1660_Series Error
    Unable to send command to printer driver!
    Unsupported format 'application/vnd.cups-command'!

    Does this comment deliver any useful debugging info?

    Respectfully yours,

    Bas.

     
  • Till Kamppeter
    Till Kamppeter
    2011-02-19

    The ML-1660 is a QPDL-3 printer. I have added support for this class of printers to the SVN repository of SpliX now.

     
  • salahuddin66
    salahuddin66
    2011-02-20

    downloading from svn. thank you

     
  • Tobias
    Tobias
    2011-02-21

    Downloaded, compiled and installed the revision 293 from svn. After that the setup of my ML-1660 works like a charm. Printing a test page with CUPS also works fine. But after the execution of the first job, the printer seems to be dead. All further jobs are normally accepted and marked as finished by CUPS without printing a page. When I restart the ML-1660 I can run another job until I get in the same frustrating situation. Any ideas whats wrong?

     
  • Till Kamppeter
    Till Kamppeter
    2011-02-21

    Seems that more than just allowing QPDL 3 is needed. Probably the procedure on closing a job to leave the printer in the correct state for the next job is different. Someone would need to compare the output of the original Samsung driver with the output of SpliX.

     
  • Tobias
    Tobias
    2011-02-21

    I'm totally new to SpliX and CUPS. But if you could tell me how I can compare the driver outputs, I would try to help.

     

  • Anonymous
    2011-02-21

    For what it is worth the same thing happened to me with certain (all?) OO.o Writer documents and the proprietary driver.  May not be related though.

     
  • Tobias
    Tobias
    2011-02-21

    Nice hint. Indeed some of my test PDFs were build by OOo, but I can't print two jobs at all. Actually printing a test page from CUPS two times fails. Obviously you are using the official Samsung driver. Perhaps tillkamppeter can tell us how to compare our driver outputs. If they are equal the failure can be caused by a broken QPDL 3 implementation of Samsung - which would be the worst case :-(

     

  • Anonymous
    2011-02-21

    While waiting for Till to provide the proper answer, which probably involves setting up the right pipeline on the command line, you can reinstall a second "copy" of each printer and change the cups configuration file to replace the output location with a file under /tmp.  You probably have to restart cups after having done this, and there may be something else needed - I have done it in the past, but it is too fiddly to keep in memory.  Don't expect the output to be identical though, I am sure that there are enough small details which the two drivers can do slightly differently without noticeably affecting the output.  If anything, I would guess that you would want to look at the start and the end of the output and work with the driver source to understand the differences.

     
  • Tobias
    Tobias
    2011-02-22

    Next update: The SpliX driver r293 works fine with my MacBook Pro and CUPS 1.4.6. My print server is at Debian + CUPS 1.4.4.

     
  • Till Kamppeter
    Till Kamppeter
    2011-02-22

    tfeith, this means that CUPS 1.4.6 did the trick for you? Which distro is running on your MacBook Pro? CUPS 1.4.6 got packaged for Ubuntu Natty (and also SpliX rev 293). Can you try booting appropriate Daily Live CDs of Natty on your boxes to see whether theis distro works for you?

    Michael, to print into a file with CUPS, you have to run the command (as root or as a user in the "lpadmin" group)

    cupsctl FileDevice=yes

    and then create a print queue with the URI

    file:/tmp/printout

    Note that I do not know about the protocol of Samsung printers. So please compare the output and tell here whgat is different and what should be fixed on the driver.

     
  • Tobias
    Tobias
    2011-02-22

    I don't know if CUPS 1.4.6 makes the difference. My MacBook runs with Snow Leopard 10.6.6 and my print server with Debian Squeeze. The print server has an arm cpu and no cdrom, so that regular distros and third party packages probably wont work, but I will have a look at the backports or try to compile CUPS 1.4.6 by myself to exclude problems are caused by CUPS.

    Your advices to print into a file are an extension to Michaels instructions or is it that simple?

     
  • Till Kamppeter
    Till Kamppeter
    2011-02-22

    tfeith, so the reason why it works on the MacBook seems to be the completely different OS. The problem why it does not work on your print server seems to be the Arm processor. It can have a Little/Big endian opposite to PCs or Macs. There are many patches concerning Endian problems in the patch tracker. I did not apply them as I have no means to test. It would be great if you could test them. In the end the upstream code must work on both Little and Big Endian boxes, so the correct patches must work with both.

     
  • Tobias
    Tobias
    2011-02-22

    The print server runs in little endian mode.

    uname -m
    armv5tej[b]l[/b]
    

    But I will give the patches a try and let you know the results.

     
  • Tobias
    Tobias
    2011-02-22

    Now the printer works *sometimes* ;). After some more tests and no changes on my setup I figured out that the printer doesn't seem to go into an irregular state or something like this. The printer seems to skip some jobs. Up to now I don't have an idea about what might be the pattern behind the printer's behavior. But it doesn't seem to be related to specific document types.

    I think I will have to debug the printer outputs to get a clue about what is going wrong.

     
  • Tobias
    Tobias
    2011-02-22

    UPDATE: Sometimes I receive the following message while printing

    Splix cannot get input slot informations
    

    But it doesn't seem to be responsible for the skipped jobs.

     
  • Look at line 84 of file src/qpdl.cpp, there is a conditional code dependent on the qpdl version, related to sending bit header info. If version 3 is compatible with version 2, then the original code:
    ---------original--------------
    if (!headerSent || version == 2) {
    -----------------------------

    should be adapted to:

    --------modified-------------
    if (!headerSent || version == 2  || version == 3) {
    ----------------------------

    Hope it is just a bit of help, look carefully if it does  not work,

    Leonardo

     
  • Hi, after reviewing in more detail, the above code doesn't do much help, because the printer is monochome. Sorry.

     
1 2 > >> (Page 1 of 2)