Nec Pinwriter P20 druckt nicht !!!
Andreas Favoccia
ich habe von einem Freund einen Nec Pinwriter P20 geschenkt bekommen.
Leider läuft er unter meinem System ( Win 98SE, K6-200, Winword, direkt am
LTP1 angeschlossen ) nicht.
Bei meinem Kumpel lief der Drucker noch einwandfrei und beim Transport ist
auch nix passiert.
Jedesmal, wenn ich was drucken möchte passiert nichts.
Obwohl, doch es passiert was, es kommt folgende Fehlermeldung:
Fehler beim Schreiben auf LTP1 für Drucker Nec Pinwriter P20.
Der Drucker ist nicht bereit. Stellen Sie sicher, das er eingeschaltet und
"online" ist.
Klicken Sie auf Wiederholen, um den Druckvorgang fortzusetzen.
Die Wiederholung erfolgt automatisch nach 5 Sek.
Wenn ich auf Wiederholen drücke passiert immernoch nichts, nur das die
Fehlermeldung wieder kommt.
Drücke ich auf Abbrechen spuckt der Drucker das eingezogene Blatt wieder
aus.
Ich habe mir auch die neusten Treiber bei Nec runtergeladen und installiert,
aber ohne Erfolg.
Was mich wundert, ich habe noch einen alten Pinwriter P22Q und da funzt das
drucken wunderbar.
Ok, beim P22Q ist der Druckkopf beschädigt, der Druck ist ziemlich blass,
aber fakt ist, er reagiert auf den Druckbefehl.
Ich habe auch den Selbst-Test beim P20 probiert und der läuft ohne Probleme
von statten.
Ich hoffe jemand von euch weiß noch Rat, weil ich denke es ist nur eine
Kleinigkeit, die ich übersehe.
Gruß
Andreas
Matthias Paul
> Fehler beim Schreiben auf LTP1 für Drucker Nec Pinwriter P20.
> Der Drucker ist nicht bereit. Stellen Sie sicher, das er eingeschaltet
> und "online" ist.
> [...]
> Drücke ich auf Abbrechen spuckt der Drucker das eingezogene Blatt
> wieder aus.
Ich gehe davon aus, daß der Drucker auch tatsächlich "online" geschaltet
ist (SELECT Taste und LED), sonst wäre die Fehlermeldung ja berechtigt.
Hat der Drucker das Blatt selbst eingezogen oder hast Du das per Hand
gemacht? Das ist interessant, um zu sehen, ob beim Drucker überhaupt
etwas Sinnvolles ankommt. Interessant ist auch, ob Du unter DOS
(ohne Windows!) problemlos drucken kannst oder nicht, z.B. mit:
TYPE C:\CONFIG.SYS > \DEV\PRN:
Wenn alle Stricke reißen, solltest Du den Drucker mal auf Hex-Dump
(LOAD/UNLOAD-Taste beim Einschalten des Druckers drücken)
umschalten und Dir genau anschauen, was dort ggfs. ankommt.
Vielleicht ist das Druckerkabel kaputt (oder zu lang?). Benutzt Du
für den P20 das gleiche Druckerkabel wie für den P22Q? Falls nein,
dann probiere das Kabel des P22Q mal am P20 aus. Die Leitungen 11
"BUSY", 13 "SLCT" und 32 "!FAULT" der Centronics-Schnittstelle
(vom Drucker zum Rechner) sind übrigens dafür verantwortlich, ob
der Rechner den Drucker als "online" oder "offline" ansieht. Falls Du
ein Meßgerät hast oder eine Kabelpatchbox hast, kannst Du mal checken,
was auf diesen Leitungen für Pegel herrschen, bzw. die Leitungen mal
testweise unterbrechen und ggfs. *rechner*seitig auf +5V (Leitung 18
rechnerseitig) oder Masse (Leitung 16 rechnerseitig) ziehen, aber
Vorsicht!
Auch einen Versuch Wert ist es, einmal einen anderen Druckerport
zu versuchen. Eigentlich ist der P20 schon viel zu "modern" um Probleme
damit zu haben, aber *ganz* alte Drucker haben schon mal Probleme mit
modernen Druckerports, die etwas zu schwachbrüstig sind, um die
alten, vergleichsweise niederohmigen Eingänge anzusteuern. Ich habe
sowas aber bisher nur bei Schnittstellen von hochintegrierten Multi-IO-
Karten aus der 486/Pentium-Zeit gesehen, wenn dort die Leitungs-
treiber eingespart wurden.
Oder einmal die Einstellungen des Drucker-Setups überprüfen, in dem
Du beim Einschalten des Druckers die SELECT-Taste gedrückt hältst.
Hat Dein Freund den Drucker vielleicht an einer seriellen Schnittstelle
betrieben? Dann müßtest Du nämlich im Drucker-Setup auf die
parallele Schnittstelle umschalten.
Ich habe nichts dergleichen im PDF-Handbuch des P20 gefunden, aber
zumindest die anderen NEC-Pinwriter (ich selbst habe den P7plus und
den P90) bieten im Setup eine Möglichkeit, die Funktion der Steuer-
sequenzen DC1/DC3 zu unterdrücken - Dein Drucker scheint diese
Kommandos grundsätzlich zu ignorien, falls Du aber doch irgendwo
einen diesbezüglichen Menüpunkt finden solltest, solltest Du diese
Funktion testweise mal ausschalten, um jede "Störung" von der
Software-Seite her auszuschließen.
Außerdem würde ich im Setup des *Rechners* sicherstellen, daß der
Druckerport auf "Standard unidirektional" steht, also "Bidir", "ECP",
"EPP" Modi abgeschaltet sind - damit kann der Drucker sowieso nichts
anfangen, und gerade auf moderneren Systemen kann das schon
mal zu Problemen führen, wenn man es aktiviert hat, ohne daß
es benötigt würde. Eigentlich sollte dann auch der P22Q damit
Probleme bekommen, aber immerhin ist der etwa zwei Jahre jünger,
so daß er vielleicht schon besser damit klar kommt.
> Ich habe mir auch die neusten Treiber bei Nec runtergeladen und
> installiert, aber ohne Erfolg.
Der neueste Treiber (für Windows 98) von NEC Deutschland ist
übrigens älter als der ansonsten baugleiche Treiber, der bei
Windows 98SE beiliegt. Nichtsdestotrotz sollten beide Treiber
problemlos arbeiten.
Würde mich interessieren, ob Du Erfolg hattest. Viel Glück!
Matthias
PS. Eine Frage, die mit Deinem Problem nichts zu tun hat:
Haben der P20 oder der P22Q irgendwo einen Einschub
für Font-Kassetten (evtl. auf der Rückseite)?
------------------------------------------------------------
http://www.uni-bonn.de/~uzs180/mpdokeng.html
------------------------------------------------------------
Dirk Ohme
> TYPE C:\CONFIG.SYS > \DEV\PRN:
das war ja der Witz des Tages *eg* *SCNR*
C:\>TYPE C:\CONFIG.SYS > \DEV\PRN:
Das System kann den angegebenen Pfad nicht finden.
Entweder (Unix, Linux): cat /etc/hosts > /dev/haumichtod
Oder (DOS, Win, OS/2): type c:\config.sys prn
(statt PRN geht aucht LPT1, LPT2, ...)
So long,
-+- Dirk -+-
Matthias Paul
ich freu´ mich auch immer über solch´ lustige Bemerkungen: ;->
Nichts für ungut, aber zu Deiner Information:
Ob "TYPE C:\CONFIG.SYS > \DEV\PRN:" oder ähnliche
geartete Konstrukte funktionieren, mag im Zweifelsfall
ja von der DOS-Version oder -Emulation abhängen -
ich weiß jetzt nicht, was Du benutzt.
Unter DR-DOS 7.03 & 7.04/7.05, PC DOS 7 & 2000,
MS-DOS 6.22 oder MS-DOS 7.10 (98SE) und allen
früheren Versionen seit 2.0 funktioniert die obige Syntax
jedenfalls (hab´s gerade nochmal überprüft - keine
Netzwerk-Software geladen), übrigens auch dann,
wenn ein Verzeichnis namens \DEV\ gar nicht existiert.
Zugegeben, das ist eine alte Konvention, die heute
(zumindest in der DOS/Windows-Welt) kaum noch
einer kennt.
Bei alten DOS-2.xx Versionen *mußt* Du das \DEV\-
Verzeichnis tatsächlich dem Gerätenamen voranstellen,
wenn Du sicherstellen willst, daß das *immer* funktioniert
(Stichwort CONFIG.SYS AVAILDEV=TRUE/FALSE).
Gerätetreiber sind unter DOS ja prinzipiell in jedem
Verzeichnis existent, aber wenn das Verzeichnis selbst
nicht existiert, würdest Du normalerweise eine Fehler-
meldung wie die Deinige bekommen (nicht so in einer
Windows 9x DOS-Box). Der Verzeichnisname \DEV\ ist
aber als Spezialfall im DOS-Kernel verankert, deshalb
funktioniert das nicht nur mit COMMAND.COM und
4DOS, sondern auch aus allen DOS-Anwendungen heraus,
und das ist auch der Grund dafür, daß Du keine Fehler-
meldung bekommen solltest, selbst wenn ein derartiges
Verzeichnis auf Deiner Festplatte nicht existiert (bei mir
tut´s das auch nicht).
Wenn das bei Dir nicht funktioniert, habe ich nur zwei
mögliche Erklärungen:
- Entweder Du benutzt eine DOS-Emulation wie die
von OS/2 oder NT. Ich habe nicht überprüft, ob es
da auch klappt oder nicht, aber Deine Fehlermeldung
entspricht jedenfalls nicht der, die der Error-Handler
von COMMAND.COM in diesen Fall ausgeben würde.
Vielleicht ist eine geladene Netzwerk-Software daran
"Schuld"?
- Oder es liegt an Feinheiten der Syntax, die Dein System
aus mir im Moment noch unbekannten Gründen nicht
akzeptiert: Der Doppelpunkt, den man üblicherweise
Gerätenamen nachstellt, ist optional, genauso wie
natürlich das \DEV\. Aber normalerweise machen
solche Spitzfindigkeiten nur innerhalb von Anwendungen
Probleme, die selbst versuchen, den angegebenen Pfad
zu interpretieren, und dabei etwas übersehen.
Du kannst übrigens auch "\DEV\PRN.123" o.ä. schreiben,
und mit COPY funktioniert diese Syntax auch. (Vielleicht
hat sich in dieser Hinsicht mit MS-DOS 8.0 tatsächlich
was geändert, für den Fall, daß Du damit arbeiteten
würdest? Aber irgendwie passen Linux und ME schon
vom Anspruch an sich nicht gut zusammen, nicht wahr...)
An dieser Stelle noch der Hinweis, daß PRN: und
LPT1: zwar üblicherweise das Gleiche sind, aber
(zumindest für manche DOS-Versionen) nicht grund-
sätzlich, und da ich vermutete, daß Andreas den NEC
als Windows-Standarddrucker eingerichtet hat,
hielt ich PRN: als Beispiel für sinnvoller.
Aber genug davon, dies ist schließlich eine Drucker-Group...
Matthias
PS. Sollte ich mich irren, würde mich das wirklich
interessieren, da ich in meinen Batchjobs bisher immer
\dev\ vorangestellt habe, ohne irgendwelche Probleme
damit zu bekommen, im Gegenteil (sonst könnte ich
es mir ja auch sparen)...
Dirk Ohme
> Nichts für ungut, aber zu Deiner Information:
>
> Ob "TYPE C:\CONFIG.SYS > \DEV\PRN:" oder ähnliche
> geartete Konstrukte funktionieren, mag im Zweifelsfall
> ja von der DOS-Version oder -Emulation abhängen -
> ich weiß jetzt nicht, was Du benutzt.
MS-DOS 3.30, DR-DOS 5.0 & 6.0, Windows NT 4, Windows 2000, OS/2 2.0 -
4.0
> Zugegeben, das ist eine alte Konvention, die heute
> (zumindest in der DOS/Windows-Welt) kaum noch
> einer kennt.
Das ist mir reichlich neu. Ich kenne die Alternative beim Pfadseparator,
auch noch aus Int21h-Zeiten, aber das mit \DEV ist mir neu.
> Bei alten DOS-2.xx Versionen *mußt* Du das \DEV\-
> Verzeichnis tatsächlich dem Gerätenamen voranstellen,
> wenn Du sicherstellen willst, daß das *immer* funktioniert
> (Stichwort CONFIG.SYS AVAILDEV=TRUE/FALSE).
^^^^^^^^
Wo ist das bitte dokumentiert? Bist Du sicher, dass Du da nicht eine
spezielle COMMAND.COM-Alternative gewählt hast? In mir bisher bekannten
Dokumentationen wurde bei Gerätetreibern grundsätzlich kein Präfix
"\DEV\" angegeben. Es hieß bspw. immer "copy con ...", "dir > lpt1",
usw. usw.
Zum Teil war es so, dass bei bestimmten Geräten das $ noch angegeben
werden musste (CLOCK$). Aber das mit "DEV" habe ist *so* noch nirgends
gelesen - weder in Hand-, noch in Programmierbüchern (u.a. zur
Treiberprogrammierung für OS/2).
Ansonsten:
C:\>ver
Microsoft Windows 2000 [Version 5.00.2195]
C:\>copy \dev\con test.txt
Das System kann den angegebenen Pfad nicht finden.
C:\>copy con test.txt
test
^Z
1 Datei(en) kopiert.
Warum sollten die was ausbauen, wenn sonst doch auf 100%-Kompatibilität
geachtet wurde?
> Gerätetreiber sind unter DOS ja prinzipiell in jedem
> Verzeichnis existent, aber wenn das Verzeichnis selbst
> nicht existiert, würdest Du normalerweise eine Fehler-
> meldung wie die Deinige bekommen (nicht so in einer
> Windows 9x DOS-Box).
Lieber Matthias, DOS basiert zunächst einmal auf CP/M - erst mit Version
2.0 von PC-DOS kamen Ansätze aus der Unix/Xenix-Welt rüber. Das bedeutet
auch, dass die Gerätetreiber historisch betrachtet Anleihen aus der
CP/M-Welt haben. Und dort ist das Konzept der Implementierung eine
andere als bei Unix. Ein Gerätetreiber existiert überhaupt nicht im
Dateisystem. Es ist gleichsam ein reservierter Name, deshalb auch
folgendes:
C:\>copy \winnt\con test.txt
test
^Z
1 Datei(en) kopiert.
Gerätetreibernamen sind aber unter DOS, Windows und OS/2 aber nicht an
ein Verzeichnis gebunden. Du kannst das "\dev\" ruhig ignorieren. Es ist
nur - anscheinend - ein Designfehler mancher Shells, dass ein Pfad
beachtet wird. Im Grunde sollte nur der Dateiname schon zur Auflösung
reichen.
Ansonsten wäre es auch reichlich sinnlos "\dev\nul" zu unterstützen,
wenn es unter Unix "/dev/null" heisst, gelle? Oder woher sollen "lptX",
"con", "aux", "comX" auch 1:1-Entsprechungen unter Unix haben? (Es gibt
aber bspw. "aux" und "con" unter CP/M!)
> Der Verzeichnisname \DEV\ ist aber als Spezialfall im DOS-Kernel
> verankert, deshalb funktioniert das nicht nur mit COMMAND.COM und
> 4DOS, sondern auch aus allen DOS-Anwendungen heraus
Wenn dem so wäre - warum dann nicht mit meinem Windows 2000? Wie gesagt:
Das Gerätetreiber-Konzept stammt von CP/M und nicht Xenix/Unix! Deshalb
ist das mit "\dev" irrelevant, da nicht aus der CP/M-Welt.
> - Entweder Du benutzt eine DOS-Emulation wie die
> von OS/2 oder NT.
Wenn Deine Aussage korrekt wäre und es sich um eine backward
compabitility handeln würde, warum wurde sie dann dort ausgebaut? Das
ist unlogisch, zumal sie ganz leicht zu implementieren wäre, ohne die
zugrunde liegenden (Sicherheits-)Konzepte zu gefährden.
> Vielleicht ist eine geladene Netzwerk-Software daran "Schuld"?
Das meinst Du nicht wirklich ...
> - Oder es liegt an Feinheiten der Syntax, die Dein System
> aus mir im Moment noch unbekannten Gründen nicht akzeptiert:
Belege bitte Deine Aussagen mit Fakten. Schau nach, ob bei Dir nicht ein
Verzeichnis "\DEV" existiert. Was passiert, wenn Du "A:\DEV\CON"
angibst?
> Der Doppelpunkt, den man üblicherweise Gerätenamen nachstellt,
> ist optional, [...]
Du vergisst auch das $, welches bei manchen (Spezial-)Geräten
erforderlich ist - siehe CLOCK$.
> Aber irgendwie passen Linux und ME schon vom
> Anspruch an sich nicht gut zusammen, nicht wahr...)
Linux und Windows (DOS) haben in der Hinsicht keine Verwandschaft! Und
CP/M ist eine eigene Welt für sich ... das Konzept der Gerätetreiber ist
sehr unterschiedlich, deshalb sollte man da einen harten Trennstrich
zwischen diesen Welten ziehen! Das "\dev\" hat bei DOS, OS/2 und Windows
nichts verloren! Denn bei CP/M gab's das nicht ...
> PS. Sollte ich mich irren, würde mich das wirklich
> interessieren, da ich in meinen Batchjobs bisher immer
> \dev\ vorangestellt habe, ohne irgendwelche Probleme
> damit zu bekommen, im Gegenteil (sonst könnte ich
> es mir ja auch sparen)...
mode /?
... und schau Dir mal an, ob dort "\DEV\" aufgeführt wird, so wie das
":" dort aufgeführt ist!
Matthias Paul
ich hoffe, daß das für die anderen nicht zu off-topic wird,
aber vielleicht ist es ja doch interessant...
> > Ob "TYPE C:\CONFIG.SYS > \DEV\PRN:" oder ähnliche
> > geartete Konstrukte funktionieren, mag im Zweifelsfall
> > ja von der DOS-Version oder -Emulation abhängen -
> > ich weiß jetzt nicht, was Du benutzt.
>
> MS-DOS 3.30, DR-DOS 5.0 & 6.0, Windows NT 4,
> Windows 2000, OS/2 2.0 - 4.0
OK, dann kannst Du es ja einfach selbst ausprobieren,
zumindest unter MS-DOS 3.30 und DR DOS 5.0/6.0
müßte es bei Dir auch klappen.
> > Zugegeben, das ist eine alte Konvention, die heute
> > (zumindest in der DOS/Windows-Welt) kaum noch
> > einer kennt.
>
> Das ist mir reichlich neu. Ich kenne die Alternative beim
> Pfadseparator, auch noch aus Int21h-Zeiten, aber das mit
> \DEV ist mir neu.
Du meinst, daß sowohl ´\´ als auch ´/´ von Kern akzeptiert
wird, nicht wahr? (In manchen Anwendungen, die auch
selbst Pfade interpretieren, wie z.B. COMMAND.COM
ist das übrigens abhängig davon, wie der SwitChar gerade
eingestellt ist, d.h. oder der gerade auf ´/´ oder ´-´ steht.)
> > Bei alten DOS-2.xx Versionen *mußt* Du das \DEV\-
> > Verzeichnis tatsächlich dem Gerätenamen voranstellen,
> > wenn Du sicherstellen willst, daß das *immer* funktioniert
> > (Stichwort CONFIG.SYS AVAILDEV=TRUE/FALSE).
> ^^^^^^^^
> Wo ist das bitte dokumentiert? Bist Du sicher, dass Du da nicht
> eine spezielle COMMAND.COM-Alternative gewählt hast?
> In mir bisher bekannten Dokumentationen wurde bei Gerätetreibern
> grundsätzlich kein Präfix "\DEV\" angegeben. Es hieß bspw. immer
> "copy con ...", "dir > lpt1", usw. usw.
Da hast Du schon Recht, aber das ändert nichts daran, daß der Präfix
\DEV wirklich als Spezialfall im DOS-Kernel implementiert ist.
Dummerweise nicht als String "\DEV", so daß man das schnell
finden könnte, sondern zusammengesetzt aus Einzelabfragen, aber
wenn Du Dir z.B. die OpenDOS Quelltexte aus dem Internet besorgst,
kannst Du das dort sehen, ansonsten müßtest Du bei DR-DOS und
MS-DOS/PC DOS den INT 21h tracen oder disassemblieren.
Das ist ziemlich haarig, aber man kann die Stelle finden...
Aber zur Frage der Dokumentation, hier z.B. ein Auszug aus
Ralf Brown´s Interrupt Liste INTER62:
--------D-2137-------------------------------
INT 21 - DOS 2.x and 3.3+ only - "AVAILDEV" - SPECIFY \DEV\ PREFIX USE
AH = 37h
AL = subfunction
02h get availdev flag
Return: DL = 00h \DEV\ must precede character device names
= nonzero \DEV\ is optional
03h set availdev flag
DL = new state
00h \DEV\ is mandatory
nonzero \DEV\ is optional
Return: AL = status
00h successful
FFh unsupported subfunction
Notes: all versions of DOS from 2.00 allow \DEV\ to be prepended to device
names without generating an error even if the directory \DEV does
not actually exist (other paths generate an error if they do not
exist); DOS 2.x has an AVAILDEV= option in CONFIG.SYS to make \DEV
mandatory
although MS-DOS 3.3+, DR DOS 3.41+, and Novell DOS 7 accept these
calls, they have no effect, and AL=02h always returns DL=FFh (except
for Novell DOS 7, which leaves AX unchanged for both subfunctions)
Die API-Funktion ist in heutigen DOS-Versionen also ein Dummy,
d.h. das \DEV ist nicht notwendig, aber eben immer noch möglich.
Zumindest bei DOS 2.xx konnte man das Verhalten umschalten,
indem man entweder diese Funktion aufrief oder in CONFIG.SYS
die AVAILDEV=TRUE/FALSE Direktive benutzt hat; die wurde
in späteren Versionen wieder abgeschafft, aber wenn Du irgendwo
noch ein DOS 2 ´rumfliegen hast, schau Dir einfach mal IO.SYS/
IBMBIO.COM in einem Binäreditor an. Aus Syntax-Kompatibilität
unterstützt übrigens auch DR-DOS 7.02+ diese Direktive.
Näheres kannst Du auch in meinem MPDOSTIP.ZIP Paket nachlesen
(siehe meine Web-Seite).
> Zum Teil war es so, dass bei bestimmten Geräten das $ noch angegeben
> werden musste (CLOCK$). Aber das mit "DEV" habe ist *so* noch
> nirgends gelesen - weder in Hand-, noch in Programmierbüchern (u.a.
> zur Treiberprogrammierung für OS/2).
Naja, das stimmt schon, aber wenn Du damit "offizielle Dokumentation"
meinst, da steht sowieso nur die Hälfte drin.
> Ansonsten:
> C:\>ver
>
> Microsoft Windows 2000 [Version 5.00.2195]
>
> C:\>copy \dev\con test.txt
> Das System kann den angegebenen Pfad nicht finden.
>
> Warum sollten die was ausbauen, wenn sonst doch auf 100%-
> Kompatibilität geachtet wurde?
Schön wäre es, wenn die wirklich auf Kompatibilität geachtet
hätten, aber leider ist die DOS-Emulation von NT (und 2000)
meines Erachtens mehr oder weniger unbrauchbar, zumindest
was die Kompatibilität mit echtem DOS angeht... Die von OS/2
ist meiner Erfahrung nach etwas besser, aber eben immer noch
kein richtiges DOS.
Alleine was das Verhalten der Kommandoprozessoren angeht,
gibt es viele kleine und große Inkonsistenzen, ständiges Thema
z.B. in JPSoft´s Diskussionsforen www.jpsoft.com (4DOS etc.)
> > Gerätetreiber sind unter DOS ja prinzipiell in jedem
> > Verzeichnis existent, aber wenn das Verzeichnis selbst
> > nicht existiert, würdest Du normalerweise eine Fehler-
> > meldung wie die Deinige bekommen (nicht so in einer
> > Windows 9x DOS-Box).
>
> Lieber Matthias, DOS basiert zunächst einmal auf CP/M - erst mit Version
> 2.0 von PC-DOS kamen Ansätze aus der Unix/Xenix-Welt rüber. Das bedeutet
> auch, dass die Gerätetreiber historisch betrachtet Anleihen aus der
> CP/M-Welt haben. Und dort ist das Konzept der Implementierung eine
> andere als bei Unix. Ein Gerätetreiber existiert überhaupt nicht im
> Dateisystem. Es ist gleichsam ein reservierter Name, deshalb auch
> folgendes:
Das ist schon klar. :-) Du störst Dich an der Formulierung, daß
Gerätetreiber
in jedem Verzeichnis existent sind. Hm, vielleicht kann man das besser
formulieren, Tatsache ist aber - wie Du ja auch schreibst-, daß Du dem
Namen eines Zeichen-Gerätetreibers jedes beliebige existierende
Verzeichnis voranstellen kannst, genauso wie Du jede beliebige
Dateiendung an den Gerätetreibernamen hängen kannst. Das ist
einfach eine Frage, wie das im Kern implementiert ist. Natürlich
muß es dafür im Dateisystem keine "Einträge" etwa unter diesem
Namen geben, und wenn dort gleichnamige Einträge wären, könntest
Du die gar nicht ansprechen, weil die Behandlung von Gerätetreibern
im DOS-Kern eben früher geschieht.
> Gerätetreibernamen sind aber unter DOS, Windows und OS/2 aber nicht an
> ein Verzeichnis gebunden. Du kannst das "\dev\" ruhig ignorieren. Es ist
> nur - anscheinend - ein Designfehler mancher Shells, dass ein Pfad
> beachtet wird. Im Grunde sollte nur der Dateiname schon zur Auflösung
> reichen.
Ich habe mich gestern auch gefragt, warum das in einer DOS-Box
funktioniert,
aber zumindest in früheren DOS-Versionen ist dem definitiv nicht so (siehe
auch die Bemerkung in RBIL): Wenn Du einen Verzeichnisnamen voranstellst,
muß das Verzeichnis auch existieren, oder der Verzeichnisname muß \DEV
heißen. Kann sein, daß das in neueren DOS-Versionen noch weiter aufgeweicht
wurde, ich vermute aber im Moment eher, daß das eher eine Implementierungs-
frage in der jeweiligen Shell ist.
> Ansonsten wäre es auch reichlich sinnlos "\dev\nul" zu unterstützen,
> wenn es unter Unix "/dev/null" heisst, gelle? Oder woher sollen "lptX",
> "con", "aux", "comX" auch 1:1-Entsprechungen unter Unix haben? (Es gibt
> aber bspw. "aux" und "con" unter CP/M!)
Und auch CP/Ms LST, das nur in manchen OEM MS-DOS Versionen wieder
auftauchte...
> > Der Verzeichnisname \DEV\ ist aber als Spezialfall im DOS-Kernel
> > verankert, deshalb funktioniert das nicht nur mit COMMAND.COM und
> > 4DOS, sondern auch aus allen DOS-Anwendungen heraus
>
> Wenn dem so wäre - warum dann nicht mit meinem Windows 2000? Wie gesagt:
> Das Gerätetreiber-Konzept stammt von CP/M und nicht Xenix/Unix! Deshalb
> ist das mit "\dev" irrelevant, da nicht aus der CP/M-Welt.
Da mußt Du Microsoft fragen. Ich denke, die legen keinen gesteigerten Wert
auf DOS-Kompatibilität, eher im Gegenteil: "Wir zeigen den Weg, ihr habt
zu folgen!" Zumindest hatte Microsoft damals einige Ambitionen, CP/M
und Unix in DOS zu verheiraten, was nicht besonders gut gelungen ist.
> > - Entweder Du benutzt eine DOS-Emulation wie die
> > von OS/2 oder NT.
>
> Wenn Deine Aussage korrekt wäre und es sich um eine backward
> compabitility handeln würde, warum wurde sie dann dort ausgebaut?
> Das ist unlogisch, zumal sie ganz leicht zu implementieren wäre, ohne
> die zugrunde liegenden (Sicherheits-)Konzepte zu gefährden.
Unlogisch ist in MS-DOS und Windows leider sehr vieles. In der
Tat ist die Sache leicht zu implementieren, die Behandlung dieses
Spezialfalls in MS-DOS/PC DOS und DR-DOS kostet vielleicht
ein Duzend Bytes. Tatsache ist, daß sie existiert; die einzige
Erklärung, die ich dafür habe, daß die das bei NT offensichtlich
nicht übernommen haben, ist, daß eben sowieso kaum einer mehr
davon weiß... ;-) In diesem Falle ist das ja auch nicht weiter tragisch,
es gibt weitaus schlimmere Lücken in der DOS-Emulation von NT.
> > Vielleicht ist eine geladene Netzwerk-Software daran "Schuld"?
>
> Das meinst Du nicht wirklich ...
Doch - warum sollte ich das sonst schreiben? ;-)
Wenn Du Dir überlegst, wie unter DOS (ich war noch davon aus-
gegangen, daß Du unter plain DOS testest) Netzwerktreiber ins
System eingebunden werden, entweder als sog. Shell oder "Wrapper"
a la Novells IPX/NETX oder als sog. Requestor via Redirector-
Interface a la ODI/VLM, dann haben diese Treiber die Möglichkeit,
das im DOS-Kern selbst implementierte Path Crunching zu übersteuern,
ganz einfach weil sie viel früher zum Zuge kommen. Je nachdem,
wie diese Treiber also programmiert sind, könnten sie das Ergebnis
also verfälschen, deswegen habe ich das erwähnt.
> > - Oder es liegt an Feinheiten der Syntax, die Dein System
> > aus mir im Moment noch unbekannten Gründen nicht akzeptiert:
>
> Belege bitte Deine Aussagen mit Fakten. Schau nach, ob bei Dir nicht ein
> Verzeichnis "\DEV" existiert. Was passiert, wenn Du "A:\DEV\CON"
> angibst?
Ein Verzeichnis namens \DEV existiert bei mir nicht. "A:\DEV\CON"
greift natürlich auf Laufwerk A: zu (und ergibt eine Fehlermeldung,
wenn keine Floppy drin ist), das ist auch völlig logisch, wenn man
sich überlegt, wie der Kern so eine FileSpec bearbeitet und unterstützt
eigentlich auch meine Aussage, daß \DEV\ ein Spezialfall ist und
unter jeder DOS-Version ab 2.0+ auch dann klappt, wenn das Verzeichnis
nicht existiert. "COPY c:\config.sys a:\dev\prn:" kommt auch beim
Drucker an, bei MS-DOS 7.10 übrigens auch bei "COPY c:\config.sys
a:\noexist\prn:", mit alten DOS-Versionen dürfte letzteres übrigens
nicht klappen...
> > Der Doppelpunkt, den man üblicherweise Gerätenamen nachstellt,
> > ist optional, [...]
>
> Du vergisst auch das $, welches bei manchen (Spezial-)Geräten
> erforderlich ist - siehe CLOCK$.
Ja, das ´$´ ist dann aber auch echter Namensbestandteil des
Gerätetreibers, der Doppelpunkt hingegen nicht, der ist "Konvention".
> > Aber irgendwie passen Linux und ME schon vom
> > Anspruch an sich nicht gut zusammen, nicht wahr...)
>
> Linux und Windows (DOS) haben in der Hinsicht keine Verwandschaft! Und
> CP/M ist eine eigene Welt für sich ... das Konzept der Gerätetreiber ist
> sehr unterschiedlich, deshalb sollte man da einen harten Trennstrich
> zwischen diesen Welten ziehen! Das "\dev\" hat bei DOS, OS/2 und
> Windows nichts verloren! Denn bei CP/M gab's das nicht ...
Was die Verwandtschaft zwischen Linux und DOS/Windows angeht,
gebe ich Dir absolut Recht. Was ich meinte war, daß ich mir nicht
vorstellen kann, daß jemand, der Linux einsetzt, auf der anderen Seite
eben ME benutzt, was allein schon vom Benutzeranspruch völlig
gegensätzig wäre. Und dem ich ja offentsichlich auch nicht so. Ich kam
darauf, weil ich mich fragte, ob diese \DEV-Geschichte vielleicht bei
ME nicht mehr klappen würde - denn das ist so ziemlich die einzige
DOS-Versionen, die ich nicht selbst benutzt habe...
Was die Verwandtschaft von CP/M und DOS angeht, DR-DOS 7.03
ist nichts anderes als CP/M-86 Version 7.3 (siehe DR-DOS
eigene BDOS-Versionsabfrage, die 73h liefert, und z.B. die
CPMVer=115 Direktive in SETUP.INI), und MS-DOS 1.0 alias
SCP QDOS ist von einigen wenigen geänderten Funktionsaufrufen
und der Einführung der FAT eine reine Portierung von CP/M-80
gewesen, natürlich ist davon inzwischen nicht mehr viel zu sehen.
Schon MS-DOS 2 wurde fast komplett neu geschrieben.
Was schließlich den Trennstrich zwischen der Unix-Welt und
DOS-etc.-Welt angeht, mir ist Unix in den meisten Dingen auch
lieber, aber ich sehe das nicht so kategorisch. In jedem Fall
existieren diese "Unix-like" Besonderheiten in DOS, da kann
man nicht mehr viel dran ändern...
> > PS. Sollte ich mich irren, würde mich das wirklich
> > interessieren, da ich in meinen Batchjobs bisher immer
> > \dev\ vorangestellt habe, ohne irgendwelche Probleme
> > damit zu bekommen, im Gegenteil (sonst könnte ich
> > es mir ja auch sparen)...
>
> mode /?
> ... und schau Dir mal an, ob dort "\DEV\" aufgeführt wird,
> so wie das ":" dort aufgeführt ist!
Nein, das wird dort nicht aufgeführt, aber das ist schließlich
nur Dokumentation, und die ist sowieso unvollständig.
Nun, in Anbetracht der Tatsache, daß das ein Drucker-Forum ist,
ist es wahrscheinlich besser, diese Diskussion ggfs. privat
weiterzuführen (oder z.B. in den FreeDOS oder OpenDOS
Mailinglisten, siehe www.freedos.org oder www.delorie.com,
wo Du herzlich eingeladen bist).
Ich denke, bisher habe wir beide was dazugelernt, nämlich
daß \DEV existiert und in reinem DOS angegeben werden
sollte, wenn man sicherstellen will, daß der Batchjob auch
unter DOS 2 sauber läuft ;) und daß das offenbar in NT´s
DOS-Emulation nicht mehr funktioniert, d.h. man sollte
besser auf diese Spitzfindigkeit verzichten, wenn ein Batchjob
auch dort laufen soll.
Was mich jetzt noch interessieren würde, ist, ob Andreas´
Drucker inzwischen läuft oder immer noch muckt...
Denn das war der eigentliche Grund für mein Post...
Viele Grüße,
Matthias
------------------------------------------------------------
Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
<Matthi...@post.rwth-aachen.de> <mp...@drdos.org>
http://mpaul.drdos.org/mpdokger.html
------------------------------------------------------------
Andreas Richter
Hallo Andreas
> ich habe von einem Freund einen Nec Pinwriter P20 geschenkt bekommen.
> Leider läuft er unter meinem System ( Win 98SE, K6-200, Winword, direkt
> am LTP1 angeschlossen ) nicht.
> Bei meinem Kumpel lief der Drucker noch einwandfrei und beim Transport
> ist auch nix passiert.
> Was mich wundert, ich habe noch einen alten Pinwriter P22Q und da funzt
> das drucken wunderbar.
> Ok, beim P22Q ist der Druckkopf beschädigt, der Druck ist ziemlich
> blass, aber fakt ist, er reagiert auf den Druckbefehl.
aus der Ferne keine Lösung für dein Problem, aber:
Schau dir mal dir Druckköpfe von den beiden an.
Möglicherweise sind sie baugleich, da der P22Q nur eine geringfügig
veränderte Weiterentwicklung des P20 ist.
Bis die Tage...
Andreas
Andreas Favoccia
sorry, das ich dir erst heute antworte, war die letzten paar Tage im Stress.
> Am 2001-03-24 schrieb Andreas Favoccia:
>
> > Fehler beim Schreiben auf LTP1 für Drucker Nec Pinwriter P20.
> > Der Drucker ist nicht bereit. Stellen Sie sicher, das er eingeschaltet
> > und "online" ist.
> > [...]
> > Drücke ich auf Abbrechen spuckt der Drucker das eingezogene Blatt
> > wieder aus.
>
> Ich gehe davon aus, daß der Drucker auch tatsächlich "online" geschaltet
> ist (SELECT Taste und LED), sonst wäre die Fehlermeldung ja berechtigt.
Ja, der Drucker ist tatsächlich "online" ( Select Taste und LED leuchtet )
>
> Hat der Drucker das Blatt selbst eingezogen oder hast Du das per Hand
> gemacht?
Nein, ich habe das Blatt mit der Load/Unload Taste eingezogen.
>Das ist interessant, um zu sehen, ob beim Drucker überhaupt
> etwas Sinnvolles ankommt. Interessant ist auch, ob Du unter DOS
> (ohne Windows!) problemlos drucken kannst oder nicht, z.B. mit:
>
> TYPE C:\CONFIG.SYS > \DEV\PRN:
Im DOS Modus druckt er erstaunlicher Weise.
UND, ich finde die Diskussion mit Dirk nett, wer nun von euch beiden recht
hat oder nicht.
Aber beide Befehle von euch funzen, egal ob mit \DEV oder ohne.
Also habt ihr beide Recht :)
> Wenn alle Stricke reißen, solltest Du den Drucker mal auf Hex-Dump
> (LOAD/UNLOAD-Taste beim Einschalten des Druckers drücken)
> umschalten und Dir genau anschauen, was dort ggfs. ankommt.
> Vielleicht ist das Druckerkabel kaputt (oder zu lang?).
Also, das mit dem Hex-Dump hab ich jetzt nicht probiert, da nicht alle
Stricke gerissen sind.
Druckt ja im DOS Modus.
Soll ich das mit dem Hex-Dump trotzdem noch probieren?
> Benutzt Du für den P20 das gleiche Druckerkabel wie für den P22Q?
Ja, ich benutze das gleiche Kabel.
> Falls nein, dann probiere das Kabel des P22Q mal am P20 aus. Die Leitungen
11
> "BUSY", 13 "SLCT" und 32 "!FAULT" der Centronics-Schnittstelle
> (vom Drucker zum Rechner) sind übrigens dafür verantwortlich, ob
> der Rechner den Drucker als "online" oder "offline" ansieht. Falls Du
> ein Meßgerät hast oder eine Kabelpatchbox hast, kannst Du mal checken,
> was auf diesen Leitungen für Pegel herrschen, bzw. die Leitungen mal
> testweise unterbrechen und ggfs. *rechner*seitig auf +5V (Leitung 18
> rechnerseitig) oder Masse (Leitung 16 rechnerseitig) ziehen, aber
> Vorsicht!
> Auch einen Versuch Wert ist es, einmal einen anderen Druckerport
> zu versuchen.
Anderer Druckerport?? Du meinst an COM1 oder COM2 ??
Also ich kann das Kabel nur an einen Steckplatz anschließen und zwar am
LTP1.
COM1 und COM2 haben beide männliche Buchsen.
> Eigentlich ist der P20 schon viel zu "modern" um Probleme
> damit zu haben, aber *ganz* alte Drucker haben schon mal Probleme mit
> modernen Druckerports, die etwas zu schwachbrüstig sind, um die
> alten, vergleichsweise niederohmigen Eingänge anzusteuern. Ich habe
> sowas aber bisher nur bei Schnittstellen von hochintegrierten Multi-IO-
> Karten aus der 486/Pentium-Zeit gesehen, wenn dort die Leitungs-
> treiber eingespart wurden.
>
> Oder einmal die Einstellungen des Drucker-Setups überprüfen, in dem
> Du beim Einschalten des Druckers die SELECT-Taste gedrückt hältst.
> Hat Dein Freund den Drucker vielleicht an einer seriellen Schnittstelle
> betrieben? Dann müßtest Du nämlich im Drucker-Setup auf die
> parallele Schnittstelle umschalten.
Das war mein erster Gedanke, das vielleicht die serielle Schnittstelle
aktiviert ist, aber dem wahr nicht so.
Die Printer Memory Settings sind genauso eingestellt, wie im PDF-Handbuch
des P20 angegeben.
> Ich habe nichts dergleichen im PDF-Handbuch des P20 gefunden, aber
> zumindest die anderen NEC-Pinwriter (ich selbst habe den P7plus und
> den P90) bieten im Setup eine Möglichkeit, die Funktion der Steuer-
> sequenzen DC1/DC3 zu unterdrücken
Also das einzige, was ich zu Steuersequenzen gefunden habe, war DCD, CTS,
DSR Signals unter Interface Settings im Handbuch.
Und die sind wie im PDF-Handbuch angegeben auf Enable geschaltet.
> Dein Drucker scheint diese
> Kommandos grundsätzlich zu ignorien, falls Du aber doch irgendwo
> einen diesbezüglichen Menüpunkt finden solltest, solltest Du diese
> Funktion testweise mal ausschalten, um jede "Störung" von der
> Software-Seite her auszuschließen.
>
> Außerdem würde ich im Setup des *Rechners* sicherstellen, daß der
> Druckerport auf "Standard unidirektional" steht, also "Bidir", "ECP",
> "EPP" Modi abgeschaltet sind
Jo, daran hatte ich auch schon gedacht, aber trotz "Normal" Einstellung im
Bios hat sich nichts getan.
> damit kann der Drucker sowieso nichts
> anfangen, und gerade auf moderneren Systemen kann das schon
> mal zu Problemen führen, wenn man es aktiviert hat, ohne daß
> es benötigt würde. Eigentlich sollte dann auch der P22Q damit
> Probleme bekommen, aber immerhin ist der etwa zwei Jahre jünger,
> so daß er vielleicht schon besser damit klar kommt.
>
> > Ich habe mir auch die neusten Treiber bei Nec runtergeladen und
> > installiert, aber ohne Erfolg.
>
> Der neueste Treiber (für Windows 98) von NEC Deutschland ist
> übrigens älter als der ansonsten baugleiche Treiber, der bei
> Windows 98SE beiliegt. Nichtsdestotrotz sollten beide Treiber
> problemlos arbeiten.
>
> Würde mich interessieren, ob Du Erfolg hattest. Viel Glück!
Leider immer noch nicht :((
> Matthias
>
> PS. Eine Frage, die mit Deinem Problem nichts zu tun hat:
> Haben der P20 oder der P22Q irgendwo einen Einschub
> für Font-Kassetten (evtl. auf der Rückseite)?
Nein, beide haben keinen Einschub. Hab garnicht gewußt, das es sowas gibt.
Hab das zufällig gestern bei meinem Zahnarzt gesehen, das es so einen
Einschub gibt.
Man lernt doch jeden Tag immer wieder was neues.
Ich hoffe du hast noch ne Idee, woran es liegen könnte, das der Drucker
nicht unter Win drucken will.
Gruß
Andreas
PS: Ich hoffe auch du, DIRK, hast noch ne Idee, woran es liegen könnte, das
der Drucker nicht unter Win drucken will.
Dirk Ohme
> Im DOS Modus druckt er erstaunlicher Weise.
Aha - hast Du die Soundkarte oder etwas anderes evtl. auf IRQ 7? IRQ 7
sollte nur der ersten parallelen Schnittstelle zugeordnet sein (Port
378h, IRQ 7). In DOS erfolgt die Ansteuerung ohne Hardware-Interrupt,
insofern kann's dort auch bei Doppelbelegung bzw. deaktiviertem IRQ
funktionieren.
Oder verwendest Du denselben Druckertreiber für P22Q auch für den P20?
Evtl. hat dann der P20 doch einen Defekt auf seiner parallelen
Schnittstelle, auf einer der Steuerleitungen. Hast Du die Steckkontakte
am Druckerkabel und am Drucker geputzt (Spiritus bzw. Kontaktspray für
Elektronik und dann abwischen)?
Andreas Favoccia
> > Im DOS Modus druckt er erstaunlicher Weise.
>
> Aha - hast Du die Soundkarte oder etwas anderes evtl. auf IRQ 7? IRQ 7
> sollte nur der ersten parallelen Schnittstelle zugeordnet sein (Port
> 378h, IRQ 7). In DOS erfolgt die Ansteuerung ohne Hardware-Interrupt,
> insofern kann's dort auch bei Doppelbelegung bzw. deaktiviertem IRQ
> funktionieren.
Dann dürfte aber der P22Q auch nicht drucken, oder?
Der P22Q druckt nämlich unter Windows sowie unter DOS ohne Probleme.
> Oder verwendest Du denselben Druckertreiber für P22Q auch für den P20?
Nein, ich benutze schon den richtigen Treiber für den P20.
> Evtl. hat dann der P20 doch einen Defekt auf seiner parallelen
> Schnittstelle, auf einer der Steuerleitungen. Hast Du die Steckkontakte
> am Druckerkabel und am Drucker geputzt (Spiritus bzw. Kontaktspray für
> Elektronik und dann abwischen)?
Könnte sein, werde mal die Kontakte säubern.
Gruß
Andreas
Dirk Ohme
[IRQ-Konflikt]
> Dann dürfte aber der P22Q auch nicht drucken, oder?
> Der P22Q druckt nämlich unter Windows sowie unter DOS ohne Probleme.
>> Oder verwendest Du denselben Druckertreiber für P22Q auch für den
P20?
> Nein, ich benutze schon den richtigen Treiber für den P20.
siehst Du - und wer sagt Dir, dass der eine Treiber es nicht ein klein
wenig anders macht und deshalb ein Hardware-Konflikt dort nicht so offen
zu Tage tritt? Ich meine, Du kannst auch mal den Nec P20 mit dem
Druckertreiber für den Nec P22Q betreiben ... schon versucht?
Andreas Favoccia
Hab ich probiert, hat leider nicht gefunzt.
Hab sogar den Referenzdruckertreiber ( Epson LQ 1500 ) genommen und damit
lief der P20 auch nicht.
Gruß
Andreas
Matthias Paul
Zunächst einmal finde ich Andreas Richters Idee, den
Druckkopf zu tauschen, sehr vielversprechend, um das
Problem einfach zu umgehen.
Andererseits finde ich es erstaunlich, daß der Druckkopf des P22Q
wirklich kaputt sein soll; ich drucke auf meinen beiden (älteren)
Druckern (P7plus und P90) seit vielen Jahren große Mengen
Listings und die Köpfe sind noch immer wie neu. Zugegeben eine
andere Liga, aber die Lebensdauer der Köpfe ist laut Handbuch
in der gleichen Größenordnung. Oder wurde der P22Q lange mit
falschem Kopfabstand (zu dicht) betrieben? Das kann den Kopf
wirklich ruinieren... Oder andersherum, ist der Kopfabstand
vielleicht einfach auf zu dickes Papier eingestellt? Sagt denn
auch der Selbsttest, daß die Nadeln defekt sind?
Wie dem auch sei, hast Du denn den Kopftausch schon probiert?
Die Druckköpfe bei meinen beiden Pinwritern sind völlig anders
aufgebaut als Deine, aber vielleicht kann man das Verfahren auf
Deine Drucker übertragen: Du schiebst den Hebel für die
Anschlagstärke in die Position für besonders dickes Papier
bzw. viele Durchschläge. Dann entnimmst Du das Farbband
und biegst die beiden Metallklammern links und rechts des
Druckkopfs ein wenig nach außen. Dann müßtest Du den
Druckkopf vorsichtig nach oben ziehen können. Sollte der Kopf
vorne am Schmetterling ("Cardholder") klemmen, ist es u.U. nötig,
auch diesen vorher auszubauen - bei mir kann man den auch einfach
nach oben wegziehen (Vorsicht: Bruchgefahr!).
Einbau in umgekehrter Reihenfolge. Aber Vorsicht, daß Du die
dünne Folie (oder Metallmaske, je nachdem wie das bei Deinem
Modell aussieht) vorne im Schmetterling nicht beschädigst, sonst
gibt´s später Papierfetzen...
> > Wenn alle Stricke reißen, solltest Du den Drucker mal auf Hex-Dump
> > (LOAD/UNLOAD-Taste beim Einschalten des Druckers drücken)
> > umschalten und Dir genau anschauen, was dort ggfs. ankommt.
> > Vielleicht ist das Druckerkabel kaputt (oder zu lang?).
> Also, das mit dem Hex-Dump hab ich jetzt nicht probiert, da nicht alle
> Stricke gerissen sind.
> Druckt ja im DOS Modus.
>
> Soll ich das mit dem Hex-Dump trotzdem noch probieren?
Das kann nicht schaden, einfach um mal zu sehen, was Sache ist.
Meinst Du mit DOS-Modus ein reines DOS, also z.B. beim Booten
von 98SE das F8-Bootmenü aufrufen und dann nur bis zur Eingabe-
aufforderung durchbooten, oder meist Du den "MS-DOS Modus",
den man aus der graphischen Oberfläche starten kann (das ist nicht
das Gleiche)? Oder meinst Du gar eine DOS-Box (Vollbild oder
Fenster)?
> > Benutzt Du für den P20 das gleiche Druckerkabel wie für den P22Q?
> Ja, ich benutze das gleiche Kabel.
Gut, dann sollte man eigentlich davon ausgehen können, daß es nicht am
Kabel liegt, obwohl es immer noch sein kann, daß der P22Q einige der
Statusleitungen zum Rechner hin anders ansteuert, als der P20, und je
nachdem, wie die Software diese Signale auswertet, die Verwendung
eines modifizierten Kabels eine mögliche Lösung wäre. Aber die Fehler-
meldung heißt ja "nicht online" und nicht etwa "kein Papier", was die
Sache noch unwahrscheinlicher macht...
> > Falls nein, dann probiere das Kabel des P22Q mal am P20 aus. Die
Leitungen
> 11
> > "BUSY", 13 "SLCT" und 32 "!FAULT" der Centronics-Schnittstelle
> > (vom Drucker zum Rechner) sind übrigens dafür verantwortlich, ob
> > der Rechner den Drucker als "online" oder "offline" ansieht. Falls Du
> > ein Meßgerät hast oder eine Kabelpatchbox hast, kannst Du mal checken,
> > was auf diesen Leitungen für Pegel herrschen, bzw. die Leitungen mal
> > testweise unterbrechen und ggfs. *rechner*seitig auf +5V (Leitung 18
> > rechnerseitig) oder Masse (Leitung 16 rechnerseitig) ziehen, aber
> > Vorsicht!
Hast Du das der Vollständigkeit halber einmal nachgemessen?
> > Auch einen Versuch Wert ist es, einmal einen anderen Druckerport
> > zu versuchen.
> Anderer Druckerport?? Du meinst an COM1 oder COM2 ??
> Also ich kann das Kabel nur an einen Steckplatz anschließen und zwar
> am LTP1. COM1 und COM2 haben beide männliche Buchsen.
Nein, ich meinte parallele Schnittstellen, also LPT2:, LPT3: (und
ggfs. LPT4:). Hast Du noch einen freien ISA-Steckplatz in Deinem
Rechner für eine ISA-Multi-IO-Karte oder eine alte Hercules-Karte?
Aber es ist eigentlich auszuschließen, daß es daran liegt, denn dann
dürfte das auch unter reinem DOS nicht klappen.
> > Ich habe nichts dergleichen im PDF-Handbuch des P20 gefunden, aber
> > zumindest die anderen NEC-Pinwriter (ich selbst habe den P7plus und
> > den P90) bieten im Setup eine Möglichkeit, die Funktion der Steuer-
> > sequenzen DC1/DC3 zu unterdrücken
>
> Also das einzige, was ich zu Steuersequenzen gefunden habe, war DCD, CTS,
> DSR Signals unter Interface Settings im Handbuch.
> Und die sind wie im PDF-Handbuch angegeben auf Enable geschaltet.
Nein, das ist was ganz anderes und bezieht sich auf serielle
Schnittstellen.
> > Außerdem würde ich im Setup des *Rechners* sicherstellen, daß der
> > Druckerport auf "Standard unidirektional" steht, also "Bidir", "ECP",
> > "EPP" Modi abgeschaltet sind
> Jo, daran hatte ich auch schon gedacht, aber trotz "Normal" Einstellung
im
> Bios hat sich nichts getan.
Hast Du mal im Gerätemanager von Windows die Einstellungen der
Schnittstelle
überprüft und sichergestellt, daß die Schnittstelle dort als normaler
Anschluß
eingetragen ist, und nicht als ECP oder so. Sollte es eine Doppelbelegung
des Interrupts geben (Dirks Idee), kannst Du dort unter Ressourcen auch den
Interrupt für den Druckerport deaktivieren, den braucht Windows für den
herkömmlichen Betrieb der parallelen Schnittstelle nämlich genausowenig
wie unter DOS. Aber eigentlich kann es auch das nicht sein, denn mit dem
P22Q funktioniert es ja...
Da alle NEC Pinwriter unter Windows sowieso intern mit dem gleichen
generischen Treiber arbeiten, der lediglich etwas anders angesteuert wird,
um die modellspezifischen Besonderheiten zu berücksichtigen, vermute ich
irgendeine Einstellung, die eben zwischen beiden Treibern anders ist:
Eigentlich habe ich nur noch eine Idee, und da ich diesen Effekt bei mir
bisher noch nicht erlebt habe, geht jetzt ein bißchen die Stocherei los:
Ich vermute, daß Du beide Druckertreiber nebeneinander installiert hast,
so daß Du schnell umschalten kannst. Welcher Druckertreiber ist denn
jetzt der "Standard-Drucker" von Windows, der für den P20 oder der
für den P22Q? Ich vermute, es ist der P22Q. Kannst Du das ggfs. einmal
ändern (Kontextmenü: "Als Standard definieren"). Innerhalb des jeweiligen
Treibers (Kontextmenü: "Eigenschaften") sind auf der "Details"-Karte die
folgenden Einstellungen interessant:
- "Anschluß für die Druckausgabe":
Sollte zumindest für den gerade angeschlossenen Drucker auf
"LPT1" stehen, vielleicht für den gerade nicht angeschlossenen
Drucker einmal auf "FILE" umstellen, so daß nicht zwei Treiber
auf der gleichen Schnittstelle arbeiten??? Wer weiß... Windows
verhält sich bei mir äußerst seltsam, wenn man diese Einstellung
ändert; in den meisten Fällen wird das Bild ein paar Sekunden
später schwarz und man muß das System im Blindflug runterfahren.
Danach ist alles wieder OK. Allerdings ist mein Rechner auch
vollgestopft mit Spezial-Hardware und sicherlich nicht representativ.
Könnte aber trotzdem sein, daß hier irgendwo ein kleiner Bug in
Windows schlummert...
- "Druckeranschluß zuweisen":
Überprüfe bitte einmal, ob Du hier für LPT1: irgendeinen
Netzwerkpfad angegeben hast. Ggfs. für den Test aufheben.
Hast Du überhaupt irgendwelche Netzwerk-Software geladen?
- "Zeitlimit: nicht gewählt":
Bei mir sind hier 15 Sekunden eingetragen, was steht da bei Dir?
- "Anschlußeinstellungen..."
"Anschluß vor dem Drucken prüfen" ist bei mir angekreuzt.
Ist das auch bei Dir der Fall? Wie auch immer, vielleicht
hilft es, die Einstellung einmal zu ändern...
> > PS. Eine Frage, die mit Deinem Problem nichts zu tun hat:
> > Haben der P20 oder der P22Q irgendwo einen Einschub
> > für Font-Kassetten (evtl. auf der Rückseite)?
>
> Nein, beide haben keinen Einschub. Hab garnicht gewußt, das es sowas
gibt.
Danke, das bestätigt meine Vermutung. (Ich brauchte diese Info für ein
Open Source Projekt - hat aber nichts mit Deinem Problem zu tun...)
Viel Erfolg! Laß uns wissen, wie Du weiterkommst...
Matthias
------------------------------------------------------------
Matthias Paul, Ubierstrasse 28, D-50321 Bruehl, Germany
<Matthi...@post.rwth-aachen.de> <mp...@drdos.org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html
------------------------------------------------------------
My homepage has moved, please update your pointers.