[PAS DE SOLUTION]Imprimante Canon LBP3000

[jibe]

Salut,

Avant d'aller casser une croûte et de faire d'autres contrôles, je pose rapidement la question okazou :

Alors que j'ai toujours installé toutes sortes d'imprimantes sur SME sans problèmes, je ne parviens pas à mettre en service une Canon LBP3000 toute neuve (sur port USB)...

Vois pas ce qui cloche... Contenu de mon /etc/printcap :

Code: Tout sélectionner

sambafax|Fax Printer:\
        :lp=/dev/null:\
        :sd=/var/spool/lpd:\
        :if=/var/spool/smbfax/bin/sambafax:\
        :sh:ff_separator:bkf:mx#0:

s400|Canon s400:\
        :server:\
        :mx#0:\
        :sh:\
        :ff_separator=false:\
        :sd=/var/spool/lpd/s400:\
        :lp=/dev/lp0:

lbp3000|canon laser lbp3000:\
        :server:\
        :mx#0:\
        :sh:\
        :ff_separator=false:\
        :sd=/var/spool/lpd/lbp3000:\
        :lp=/dev/usb/lp0:


J'ai lancé un job :

Code: Tout sélectionner

lpc status all
Printer           Printing Spooling Jobs  Server Subserver Redirect Status/(Deb
ug)
sambafax@e-smith    enabled  enabled    0    none    none
s400@e-smith        enabled  enabled    0    none    none
lbp3000@e-smith     enabled  enabled    1    none   13126


et l'imprimante ne bronche pas... Pas étonnant que des jobs (supprimés depuis) lancés depuis des posts clients ne soient jamais sortis !

Quelqu'un a eu ce problème ? Ou une idée d'où il peut venir ?

Bon, je vais tester l'imprimante sur une autre bécane en attendant... C'est peut-être bien un truc tout c*** dans ce genre !

[jibe]

Re...

Bon, ben là, je sèche

L'imprimante et le câble USB fonctionnent à merveille sur une autre bécane, quant à la sortie USB elle servait il y a 2 jours à une autre imprimante : difficile de la mettre en cause également...

Semble pourtant que tout se passe bien, jusqu'au moment où les données devraient partir vers l'imprimante... Rien ne se passe à ce moment-là, et le job reste en queue...

Je ne vois plus quoi vérifier...

[adili]

Bonjour,

J'ai eu le même problème avec une LPB 800, les imprimantes Canon ont une interface GDI, elles n'ont pas de processeur embarqué et ne fonctionnent qu'avec MsWindows.
AD

[jibe]

Salut,

Merci pour ta réponse. Pas pensé à ça

Mais es-tu sûr ? Canon propose pourtant un driver Linux... C'est du reste affiché assez visiblement dans la page deprésentation de l'imprimante.

[adili]

Hello,


Au moment de mon blème, ce driver était payant, maintenant je ne sais pas, de toute façon les imprimantes canon sont bannies dans ma société.
AD

[jibe]

Salut,

Merci pour ces précisions. Mais je reste quand même dubitatif sur le fait que la LBP3000 soit une imprimante GDI : le dirver (gratuit) linux est fourni, alors que sur le site canon, il n'est pas question de linux pour la LBP800 que tu as tenté d'installer.

Je tenterais bien d'installer le driver sur SME, mais :
- Je n'ai jamais eu besoin auparavant de monter le moindre driver sur SME (puisque SME ne fait que mettre l'imprimante partagée sur le réseau et que c'est sur le poste client qu'on monte le driver),
- Le driver nécessite CUPS, que je devrais aussi installer. Si c'est - comme je le crains - pour constater que ce n'est pas mieux, j'hésite...

Quelqu'un aurait-il une idée, une piste, un début d'explication ?
Comment pourrais-je m'assurer que cette imprimante est ou n'est pas GDI ? Le fait que ce ne soit pas mentionné et qu'il existe un driver linux n'est-il pas suffisant ?

[adili]

Salut,


Je ne voudrais pas jouer les pessimistes, mais sur le site canon il est bien précisé qu'elle fonctionne avec la famille Windows et comme il n'y a aucune indication sur sur l'interpreteur (pcl scsi ou autre) est un signe plutot négatif.
Désolé
AD

[jibe]

Salut,

sur le site canon il est bien précisé qu'elle fonctionne avec la famille Windows

Mmmoui... Peut-être as-tu raison, mais sur le site canon, ce que je vois surtout, c'est qu'il y a un driver linux... Ce n'est qu'en cherchant bien qu'on voit qu'il n'est question que de W$; et je n'y aurais même pas prêté attention (dans ce monde ou, semble-t-il, seul W$ et les produits M$ existent) si tu ne me l'avais pas signalé. Si c'est effectivement une imprimante GDI, c'est quand même grave que ce ne soit pas mentionné au moins aussi visiblement que l'existance du driver linux : c'est limite publicité mensongère...

En plus, comment une imprimante GDI pourrait-elle fonctionner sous linux ? Le driver implémente les fonctions GDI nécessaires ?

D'autres ont un avis sur la question ou une expérience ?

[micjack]

Salut,

Si tu imprime en mode "RAW" il n'y a pas besoin de pilote Linux. Les pilote utilisés seront ceux de Windows.

Alors, vite fait de memoire, je m'explique:
Dans l'inteface de CUPS, tu déclare une nouvelle imprimante et tu lui donne un nom, ici LBP3000 et tu choisi le port d'impression, puis choisir comme mode d'impression RAW.

Par contre il faudra imstaller le pilote LBP Windows sur chaque postes du réseau et choisir comme port "l'URL de ta SME" genre http://192.168.1.10/printers/LBP3000

Un peu comme une imprimante réseau... En fait, ce n'est ni plus ni moins un port deporté qui s'appele "internet printing" (Il y'a une mise à jour sur le site de microsoft pour pouvoir utiliser "internet printing" pour Win98)

Les Jobs sont gérés de la même maniere, donc par CUPS...

J'ai mon imprimante qui fonctionne comme cela, et ca marche du tonner... La configuration des impressions par directement des postes du réseau comme si l'imprimante était branchée sur le poste Windows.

Par contre, j'ai jamais testé avec un port USB

[jibe]

Salut micjack,

Merci de t'intéresser à mon cas

Oui, tout se passe bien comme tu dis, et je confirme : y compris pour les imprimantes branchées sur un port USB. Je l'ai expérimenté plusieurs fois sur serveur SME.

C'est même encore plus simple, puisque la SME intègre Samba, et que l'imprimante est vue par les clients comme une simple imprimante partagée. Du coup, ça marche sans problèmes et sans ajouts depuis des postes W98 (je ne suis plus très sûr, mais je crois l'avoir aussi expérimenté avec W95 !)

Seule petite nuance : SME n'a pas CUPS installé d'origine. La queue d'impression est gérée de manière traditionnelle sous linux par lpr, lpc etc. mais en fait, ça ne change rien sur le principe. Je crois que certains ont installé CUPS, mais je n'ai jamais étudié la question et je me demande un peu comment ça peut se passer, dans la mesure où SME n'a pas de serveur X. Probablement, dans ce cas, CUPS est géré via lynx, ou on n'utilise pas l'interface web ?

En fait, mes questions sont :
- Pourquoi la LBP3000 ne fonctionne pas avec la SME, alors que tous les autres modèles que j'ai pu installer ont fonctionné du premier coup sans aucune difficulté ?
- Et donc, comment la faire fonctionner ?
- Est-il exact que la LBP3000 est une imprimante GDI ?
- Si oui, cela l'empêche-t-elle de fonctionner si elle est connectée à ma SME, étant donné que, comme tu le dis si bien, "En fait, ce n'est ni plus ni moins un port deporté" et que c'est un poste Windows qui, finalement, la pilote ? (on verra après pour les postes clients pour Linux, mais cela ne devrait pas poser de problème en installant le driver).

[micjack]

Seule petite nuance : SME n'a pas CUPS installé d'origine.

Il me semblait pourtant que CUPS était installé..

je me demande un peu comment ça peut se passer, dans la mesure où SME n'a pas de serveur X. Probablement, dans ce cas, CUPS est géré via lynx, ou on n'utilise pas l'interface web ?
..... on verra après pour les postes clients pour Linux, mais cela ne devrait pas poser de problème en installant le driver

Ah, ok il me semble comprendre que tu souhaiterais imprimer depuis ta SME.. La effectivement, avec la méthode décrite ce n'est pas possible, puisque aucun pilote n'est installer sur le Linux.

Mais installer des pilotes sur CUPS c'est possible, et comme avec Samba cela revient au même.. L'alternative est une question de pilote. Si y'a pas sur l'un, faut voir si ils existent sur l'autre.

Par exemple
N'éyant pas de serveur 24/24, donc pas de Samba, j'ai mis en oeuvre cette facon pour utiliser mon firewall comme serveur d'impression (Bien pratique pour les postes en Wifi ).

Et effectivement pas de serveur X, CUPS est administrable à distance. De plus quand je vois le nombre de RPM qu'il faut installer pour CUPS, y'a de quoi peter un cable rien que pour pouvoir utiliser l'imprimante connectée au poste..

Si non, pour les pilotes pour CUPS , il faut passer par le site linuxprinting. Il y'a de la LBP visiblement géré par le package "Ghostscript" Ici la liste de pilotes --> http://www.linuxprinting.org/driver_list.cgi

Si non,

- Et donc, comment la faire fonctionner ?
- Est-il exact que la LBP3000 est une imprimante GDI ?

J'ai le souvenir profond de m'etre fais c*hier grave avec une LBP qui ne voulait pas imprimer sous DOS, et on m'a effectivement confirmé qu'elle sont dédiée Windows.. Maintenant, je ne vois pas d'objection que le pilote soit réecrit à la sauce Linux (Comme dans la liste du lien plus haut)

- Si oui, cela l'empêche-t-elle de fonctionner si elle est connectée à ma SME

En logique oui, tant que tu ne trouve pas de pilote réecrit, retranscrit.

étant donné que, comme tu le dis si bien, "En fait, ce n'est ni plus ni moins un port deporté" et que c'est un poste Windows qui, finalement, la pilote ?

C'est exactement cela, on va dire que le poste Linux sert de passerelle pour imprimante.

Les postes en réseau peuvent fonctionner dans les deux cas, avec ou sans pilote pour Linux... Donc, soit par Samba, et la c'est comme sur du Windows , c'est une imprimante partagée.

Soit par CUPS,
1) Avec des pilotes Linux et on imprime depuis le poste local et par le réseau.
2) Sans pilote, se sont les postes du réseau qui pilotent l'imprimante et le Linux ne peut imprimer.

Donc, si tu n'a pas l'utilité d'imprimer sur ta SME, la solution 2 suffit et de plus c'est rapide comme soilution.

Cela ne repond pas à ta question, mais c'est juste pour donner une autre solution.

[jibe]

Salut,

Merci pour tes explications, micjack.

Non, je ne veux pas imprimer depuis ma SME (vraiment pas d'utilité ), mais simplement, j'essayais de voir en lançant un job quelconque depuis ma SME si l'imprimante réagissait ou non. Je pose donc ma question autrement :

Je ne parviens pas à faire marcher depuis un poste client windows la LBP3000 installée sur la SME. Pour tenter de déterminer d'où vient le problème, puis-je lancer un job depuis ma SME - ou une autre manip - dans le simple but non pas d'imprimer une page test, mais simplement de voir si l'imprimante réagi (imprime quelques hiéroglyphes, fait clignoter ses voyants ou autre) et m'assurer ainsi qu'elle reçoit bien ce qui arrive sur la SME ?

Je ne sais pas si j'ai vraiment besoin de faire ce test, mais d'après ce que tu me dis, qu'elle soit ou non dédiée windows (sûr pour la LPB800, mais beaucoup moins sûr pour la LBP3000...) elle devrait fonctionner si elle est en partage samba par ma SME et que les postes clients ont bien le driver installé ? Or, elle ne fonctionne pas... Et je ne vois pas que faire pour cerner le problème ni même savoir s'il provient du poste client ou de la SME... Tout ce que je sais, c'est que l'imprimante est bien trouvée par windows comme partagée par la SME (visible dans le voisinage réseau).

[sibsib]

Hello,

JiBé, je crois que tu as faux dans l'analyse du problème GDI printer : Dans ma compréhension, l'imprimante GDI fait surtout des économies de processeur et de mémoire. C'est donc le processeur du p.c qui est sollicité. Jusque là on est d'accord, je pense.
Mais dans ce que j'avais compris, l'imprimante GDI communique en temps réel avec le p.c. Comme, via un réseau, ceci n'est pas possible (Plutôt : ce n'est pas souhaitable, pour un spool d'imprimante), donc une partie du traitement (je suppose les contrôles de bons fonctionnement) sont fait par le P.C. qui détient l'imprimante.

Donc, si ce que j'élucubre présente un semblant de vérité, il se pourrait qu'un driver 'maison' doive être présent sur le serveur SME.

Attention : je ne suis pas vraiment sûr de ce que j'écris

Eventuellement, pour le test, peux tu mettre cette imprimante derrière un PC et booter une kaella/knoppix pour voir si tu peux en faire quelque chose ?
Après, si tu y arrives, et s'il est possible d'arrêter le SME, boot sur la meme kaella/knoppix, pour être sûr du hard.

A+,
Pascal

[micjack]

Si non Jibe, pour résumer et repondre à ton dernier post..

Mon cas qui rejoint le tien : Imprimante BJC-3000, jet d'encre, sans Samba, puisque le poste local est un Firewall avant tout (D'ou le probleme pour te filer un coup de main pour SME et sur Samba)

Ainsi, même probleme, si je me suis mis à utiliser les pilotes d'impression par le réseau, c'est justement que je ne pouvait rien en tirer sur le poste local (Installation des pilotes CUPS, avec le lien que je t'es donné plus haut) impossible de lancer une impression, même en ligne de command..

Comme toi, en local la file d'attente s'effectuait, mais aucune reaction de l'imprimante, j'ai alors utilisé le mode d'impression "internet printing" RAW , puisque c'est avant tout les impressions par le réseau qui m'interessait...

Note, qu'une file d'attente peut quand s'éffectuées, même si il n'y a pas d'imprimante d' installée.

Attention, qu' il y'a souvant des problemes d'autorisations réseau, par exemple interdiction d'écriture sur le disque (files d'attentes job) donc sur le local 127.0.0.1 si les données arrivent depuis le Lan.

Si tu veux imprimer depuis le réseau, c'est une des méthodes que je t'ai donné plus haut, mais si c'est pour t'em*erder à installer les RPM CUPS , alors que tu a Samba, alors, je ne sais plus, car d'une maniere comme d'une autre, il faut que tu install des RPM, soit CUPS sans pilote, soit des pilotes compatibles pour Samba...

Je ne sait pas si cela a une importance pour toi, mais avec CUPS, tu n'aura pas ton imprimante gérée par Samba, donc port Netbios, mais par un port bien à part 631. Deux gestions differentes.

Et la c'est un choix, comme je n'utilise pas SME, je ne puis t'aider d'avantage

EDIT cinq minutes plus tard: Je viens juste de prendre connaissance de ton post Sibsib. Y'a du test supplémentaire dans l'air (pas mal l'idée d'un Live CD, car distrib bien plus à jours )

Si non,

Dans ma compréhension, l'imprimante GDI fait surtout des économies de processeur et de mémoire. C'est donc le processeur du p.c qui est sollicité. Jusque là on est d'accord, je pense.
Mais dans ce que j'avais compris, l'imprimante GDI communique en temps réel avec le p.c. Comme, via un réseau, ceci n'est pas possible (Plutôt : ce n'est pas souhaitable, pour un spool d'imprimante), donc une partie du traitement (je suppose les contrôles de bons fonctionnement) sont fait par le P.C. qui détient l'imprimante.

Les LBP sont des imprimante dédiées Windows par une surcouche logiciel étudiée par Canon et M$, mais interpolable à Linux.. (Reste aux DEV Linux puristes de le faire) Moi, de mon coté, impossible d'en tirer quoi que ce soit sous DOS il y'a de ca 5 ans, depuis je ne veux plus enttendre parler de LBP...

En fait, c'est comme le topic sur les modem PCI...
Les "Winmodem" sont dédiés Windows et demandent exclusivent les ressources Windows.. Pour Linux, ils devraient s'appeler "Linmodem" ( interopérabilité )

Les modem dénudés de chipset de communications, sont gérés par le CPU (émulation du chipset + fonctions MMX prévues pour) ainsi que éventuellement par la complémentarité de l'OS...

Mais dans le cas précis de Jibe, je ne pense pas qu'une imprimante laser demande de la ressource CPU (Manquerait plus que ca, que les constructeur fassent agir de la CPU pour une Laser ), par contre, une ressource dédiée sur une implantation graphique gérée par l'OS , ça oui

[jibe]

Salut,

Merci à tous les deux pour vos explications et suggestions.

Bon, donc, c'est effectivement pas gagné, et je commence à comprendre pourquoi. Il ne me reste plus qu'à décider quoi faire, sachant que les tests par knoppix que me propose sibsib ne pourront que me rassurer quant à l'état du hardware, dont je suis déjà sûr à 99%. Mais comme s'emm*** plus pour faire fonctionner tout ça coûtera en temps au moins 10 fois le prix d'une imprimante vraiment compatible, je pense que c'est vite vu