Solved Samsung ML-1660 working on Linux but not on FreeBSD

spanglefox

spanglefox

Following on from my previous post I have managed to get printing to work via CUPS, being a self admitted amateur at printing on UNIX-type operating systems.

I have been trying to get a Samsung ML-1660 working in FreeBSD without success. Oddly if I use Ubuntu (which uses CUPS as the printing backend) to set up the printer everything works fine (see attached file).

I did discover that the printer appears to require GDI language. I initially tried using the GDI (Foomatic in FreeBSD) filter for CUPS but when I thought I had cracked it the machine printed an error (see second attached file).

I had installed the print/splix ports but I could not see where to add this filter. (thanks shepper for reminding me)

It is not critically important but I am just enjoying the challenge of learning how to make this work. Any suggestions gratefully received in advance.
 

Attachments

  • rsz_20150716_145745.jpg
    rsz_20150716_145745.jpg
    78.3 KB · Views: 3,049
  • rsz_20150716_145756.jpg
    rsz_20150716_145756.jpg
    51.5 KB · Views: 785
The filter you need is print/splix. OpenPrinting does not list the ML-1660 but does have a *ppd for the ML-1661. Hopefully the 1661 is close enough to the 1660 (I added Edit 2 that should give you the exact ppd ). This Thread 50281 shows multiple ways to set up filters using the LPD print spooler. If you are using CUPS you can just load the samsung ppd.

I had installed the print/splix ports but I could not see where to add this filter. (thanks shepper for reminding me)
Click to expand...

Edit 1: The *ppd should contain a line that calls the samsung filter - you should not need to add anything.

Edit 2: There is a Ubuntu howto that mentions a Unified linux *ppd for the MX-1660. With the FreeBSD splix packages intalled, you should be able to copy the MX-1660 ppd from your linux system to /usr/local/share/cups/model/samsung/ml1660.ppd and configure cups using the http://localhost:631 web interface. Make sure the owner/group and permissions are the same as the other samsung *ppd's on your FreeBSD system.
 
Sorry about the blank file from OpenPrinting - The site has fallen into disrepair as of late and I should have validated the ppd before posting. You should be able to use the Ubuntu ppd which would be in /usr/share/cups/model/samsung/ on your Ubuntu system.
 
Yes, I thought about that earlier and could not find on Ubuntu was using find / -name 'ml1660.ppd' turns out that is not the file name Ubuntu uses. It was Samsung-ML-1660-Series.ppd literally just copying over from USB stick into /usr/share/cups/model/samsung/.......

Edit: /usr/local/share/cups/model/samsung even
 
shepper said:
Sorry about the blank file from OpenPrinting - The site has fallen into disrepair as of late and I should have validated the ppd before posting. You should be able to use the Ubuntu ppd which would be in /usr/share/cups/model/samsung/ on your Ubuntu system.
Click to expand...

Hit a snag......
Code: 
"SpliX Invalid PPD file version: SpliX V. 2.0.0 but the PPD file is designed for SpliX V. 2.0.0"
was the result from CUPS
 
spanglefox said:
Hit a snag......
Click to expand...
Well this is not going smoothly. The pkg_plist indicates that the filter code is pstoqpdl along with a raster converter rastertoqpdl. It also says that the FreeBSD version of print/splix is 2.0.0 .

Can you
$ less Samsung-ML-1660-Series.ppd | grep qpdl
and
$ less Samsung-ML-1660-Series.ppd | grep qspl
to see what filter is used?

Edit:

I found this link and it suggests that the 1660 series uses a different filter: rastertosamsungspl

I would label this printer as not natively supported in FreeBSD. You could:
1) Try ml1640.ppd that came with FreeBSD print/splix
2) See if you could get it working with linux(4) emulation.

Personally, If you have access to other printers I would look for a supported model - the OpenPrinting site is a reasonable place to check, especially for older models.
 
Yes, it is a tricky. Currently back at home and having a little rest from it. I like the idea of the Linux emulation. Will dig into that a bit more tomorrow. Thanks so far for your assistance!

Currently the printer is also setup as a raw device (on a separate machine) that then is shared via CUPS & Samba to a terminal server. It prints but often the user has to power off and on again between prints. It was attempting to do away with that as the machine also has a Dymo labeller installed which when shared through CUPS & Samba works flawlessly.

Sadly this is in an office of accountants and there is more than one of these models kicking about. Double the trouble when explaining that because it says "printer" on the box doesn't mean they were all created equally......

I will try those suggestions tomorrow. Failing that I could always try the Ubuntu route if it will give a little more reliability to the user.
 
I've never set it up but my understanding is that you could have the printer attached to a samba share on a Linux computer and access that Samba share from your FreeBSD machine. I would also wonder if the need to power off/on has to do with resetting the USB port?

USB

USB printers can be connected to any available USB port on the computer.

When FreeBSD detects a USB printer, two device entries are created: /dev/ulpt0 and /dev/unlpt0. Data sent to either device will be relayed to the printer. After each print job, ulpt0 resets the USB port. Resetting the port can cause problems with some printers, so the unlpt0 device is used instead. unlpt0 does not reset the USB port at all.
Click to expand...
 
It is all a bit "quirky". The setup is FreeBSD host with the ML-1660 attached alongside a Dymo LabelWriter 450. The ML-1660 is currently set to raw but the Dymo has the proper filter. These two printers are picked up by Samba and connected to by a Microsoft Windows Terminal Server, or Remote Desktop as it likes to be called these days.

If the ML-1660 is powered off the Dymo will not function. If the printers are working it seems pot luck with some times having to power cycle the ML-1660 every print or not. There is no consistency. I did originally try the reset and non reset connections but did not result in any change. I could set the printer to redirect via the Remote Desktop software rather than share via Samba. I doubt that will work as usually that only works well with standalone working printers, rather than the version I have where Windows is doing some of the printing work.
 
Just for grins I looked at the current splix version in OpenBSD. In OpenBSD revision 1.5 (based on Splix 2.0.1), they have done away with including the *ppd files and just provide the drivers. In the earlier revision, 1.4 (Splix 2.0.0), the PLIST shows share/cups/model/samsung/ml1660.ppd. This makes me wonder if you can do a crude hack and rename the filters in your ubuntu ppd to the filters in the FreeBSD splix package, or soft link, or use OpenBSD
 
I can't offer any advise on the printer situation but a small pedantic thing to point out is emulation and compatibility are different concepts. The linux(4) module provides ABI compatibility by translating system calls on the fly rather than emulating them. It's a similar idea to Wine and it's interesting "Wine Is Not an Emulator" name where Windows libraries and kernel calls are translated on the fly.
 
Thanks for all the suggestions so far. Sadly it is the weekend and now I won't have access to this printer until next week.

In other news I did get an OKI ES5462w printer to work using a generic Postscript driver. All these experiences are slowly filling the gaps of knowledge working with CUPS!!:)
 
Hehe! I might just! I could never find the model listed with the 'w' on the end on the manufacturer's website.

I also tried using a generic PCL6 driver which also worked because on the model specification page it listed PCL6 and Postscript emulation. Would I correct in thinking that should a printer list a particular language, such as PCL6, then I would generally use a generic driver for such? I know that sounds a little silly question but rather than try out lots of printers to see if it is true.
 
wblock@ said:
That's a little surprising. A "w" prefix on a model name often means that it is a host-based "winprinter".
Click to expand...
Lately it has been used to signify "wireless" capability.

spanglefox said:
Would I correct in thinking that should a printer list a particular language, such as PCL6, then I would generally use a generic driver for such?
Click to expand...

Historically, PCL printers were cheaper as the host computer would do some of the processing prior to sending the print job in a PCL format. More expensive Postscript printers bypassed the conversion (filtering) and processed the printjob directly. There is not a pat answer as to which one you should use. If your postscript printer has limited memory you might do better processing a large complex image using the ghostscript based ps2pcl filter. The time to print is also related to the printers cpu speed. WinPrinters, aka paperweights, dispensed with cpu's/memory and relied entirely on the host computer.
 
Last edited:
spanglefox said:
Would I correct in thinking that should a printer list a particular language, such as PCL6, then I would generally use a generic driver for such?
Click to expand...
Yes. The problems in that situation are that additional features the printer might support might not be usable with the generic language.
 
Yes, it is a wireless printer. Part of the 'fun' today was replacing a router. Someone digging this printer out of the depths and then informing me that the administrator password had been forgotten.......

As for the generic languages I thought as much. I guess the additional features would be related to options such as double sided printing, paper tray options? Or something more involved with printer languages? Hmmmm.....maybe I should research PCL, etc on wikipedia and see where that goes.....
 
PostScript usually has ways to use other options. Most can be found from the PPD file, which has the PostScript commands to do special things on that specific model of printer. Other languages might. PostScript is what you use when you want it to probably print right, in the same way that an inkjet is the printer you buy when you don't really want to print anything.
 
Hello All,

Well this has been solved by someone conjuring up a Kyocera Mita FS-1010 and replacing the Samsung. Again the good news is that I have acquired enough CUPS experience to get the printer running and shared successfully via Samba.

I could take the Samsung home and tinker ad infinitum there but I think it would be a wasted effort as by the time I got it working they may have bought some new printers anyway.

Thanks all for your help and gaining experience with CUPS and printer languages\support!
 
spanglefox said:
It is not critically important but I am just enjoying the challenge of learning how to make this work. Any suggestions gratefully received in advance.
Click to expand...
spanglefox said:
I could take the Samsung home and tinker ad infinitum there but I think it would be a wasted effort as by the time I got it working they may have bought some new printers anyway.
Click to expand...

It is always a relief to get things working and in a commercial environment, leave well enough alone. From the stand point of learning, you have the print/cups way down pat. If you have the luxury, perhaps at home, you may want to try lpd(8) printing. Instead of Bells and Whistles (network discovery, accounting, maintainance utilities etc), lpd(1) has a simple elegance. The Samsung ML-1660 should set up fine in OpenBSD using OpenBSD packages, cups-filters (foomatic-rip) and splix (use Samsung Universal ppd). There are package readme's, actually using a Samsung printer as an example.
 
Last edited:
Yes, the user is very happy that her printer now just spits out anything that she decides to press the print button to. I did make it interesting and bet that it will print everything she wants up to the end of the week and if it does I win a chocolate bar! Hehe We did have an issue with the Kyocera picking up the paper, however, this was solved by adding a small elastic band to the pick up roller to provide enough friction to grab the paper.

lpd(8) is next on the list.....Will be looking into that. Sadly today with cloud technologies I don't actually personally print much and people are reluctant to let me loose on their printers Hehe.

As for the Samsung. I did have another thought\idea from the Handbook. Install as pure RAW printer and access directly from Windows using the http:// printing feature (https://www.freebsd.org/doc/en_US.ISO8859-1/articles/cups/printing-cups-clients.html).
Again most of this is time limited and dependent upon my job list. I have to next work on network link aggregation for a server and thanks to FreeBSD I have been accepted back into University to study Computer Science and Networking so come September I am sure that I will have my hands full! :)

Thanks once again!:beer:
 
I had terrible times with Samsung ML1640 (noted as working in Splix/CUPS website).

I think the issue is with the on-board RAM available with this printer. I may be wrong but I recall that the Samsung ML1640 uses system RAM to print (Windows drivers of course).

Lately, I decided to buy Fuji/Xerox network (cheapest) printer and didn't have an issue to date.

The biggest problem with Samsung was when I try to print a single page (mostly for my kids homework) I did end up about an hour in troubleshooting than actually get the work done.

Sometimes it is better to spend the money and get the things working than spending all the time troubleshooting.

I must admit though the Samsung printer worked flawlessly with Debian ( Samsung proprietary drivers).

Cheers
 
It wasn't 100% technically solved but someone did manage to burn it out so it was replaced by a Postscript printer. So "solved".
 
You must log in or register to reply here.
Back
Top