Hallo zusammen,
ich möche gerne an meinem Rechner mit Win XP Signale via Batch Datei am
Parallelport ausgeben.
Über die Suche im Forum und beim Onkel G... habe ich herausgefunden,
dass seit XP eine spezielle dll-Datei nötig ist und das es ausreichend
Beispiel-Code gibt, wie die Programmierung vorgenommen wird.
Leider finde ich keinen Beispielcode für batch files. Ich habe
Programmierung in C und Visual Basic gefunden.
Ich wäre für einen Link oder ein Tutorial dankbar, welches die
Programmierung der batch files mit Ausgabe von Signalen am parallelport
beschreibt.
Hintergrund:
Ich führe via batch-file eine Programmierung von µC durch. An einem
anderen PC muss ich bestätigen, dass die Programmierung erfolgreich war
und die Programmierschnittstelle umschalten, um einen zweiten Controller
zu programmieren.
Bis auf diese Bestätigung passiert alles andere automatisch.
Meine Vorstellung ist nun, nachdem die Programmierung stattgefunden hat,
ein Signal über parallel-port auszugeben (zb. 0b0101), das wiederum vom
anderen Rechner eingelesen werden kann. Dieser reagiert, schaltet die
Schnittstelle um und ich kann ohne manuelle Bestätigung die weitere
programmirung starten.
Vielleicht helfen mir auch die richtigen Suchworte...
Mike schrieb:> Meine Vorstellung ist nun, nachdem die Programmierung stattgefunden hat,> ein Signal über parallel-port auszugeben (zb. 0b0101), das wiederum vom> anderen Rechner eingelesen werden kann.
Warum kein Netzwerk? Da braucht man kein Parallelportgefrickel.
Mike schrieb:> ich möche gerne an meinem Rechner mit Win XP Signale via Batch Datei am> Parallelport ausgeben.
Das ist nicht vorgesehen. Per Batch lässt sich der Parallelport nur in
seiner Funktion als Druckerinterface ansprechen - du kannst also dem
Drucker an LPTx eine Textdatei schicken zum Druck.
Georg
Seit - ich glaube - Windoof 95 - kann man die Druckerschnittstelle, aus
einem Programm heraus, nicht mehr direkt erreichen. Zumindest Anno
Windoof 3.1 ging das noch.
Um diese Restriktion zu umgehen, haben einige Zeit lang Dll's existiert,
die eine Umgehung des Betriebssystems, an dieser Stelle, ermöglicht
haben. Seit dem der Parallelport aus den meisten Rechnern verschwunden
ist, haben es die Dll's ihm gleich getan.
Um keine Missverständnisse aufkommen zu lassen: Diese Dll's haben es
Programmen ermöglicht am Parallelport herum zu fummeln. Aber nicht einem
Batch-Prozess. Natürlich kann es sein, dass jemand einen Wrapper
geschrieben hat, der genau dies ermöglicht, mir ist aber keiner bekannt.
Also wie schon Günter und Georg geschrieben haben...
Amateur schrieb:> Seit - ich glaube - Windoof 95 - kann man die Druckerschnittstelle, aus> einem Programm heraus, nicht mehr direkt erreichen.
Du darfst auch "Windows" schreiben.
Tatsächlich ist das direkte I/O-Gefrickel unter ernstgemeinten
Windows-Versionen noch nie möglich gewesen (das beginnt mit NT 3.1 von
1993).
Nur die Frickelversionen 95 bis Me erlaubten das aufgrund ihres
DOS-Unterbaus (den Windows 3.1 natürlich auch hatte). Seit "Windows
2000" aber ist jedes Windows eine Version von Windows NT, auch wenn das
nicht mehr im Namen geführt wird.
Die Betrachtung aber ist müßig; zur Signalisierung zwischen zwei PCs
gibt es nur wenige noch ungeeignetere Schnittstellen als den
Parallelport.
Netzwerk. Auf dem einen PC eine Datei erzeugen/kopieren und diese dem
anderen PC senden, dessen Programm in einer Schleife o.ä. darauf wartet.
Das ist noch mit Batchmitteln umsetzbar.
Zunächst vielen Dank, für die Antworten.
Das mit Windows und den DLLs wuste ich bereits, siehe Post am Anfang.
Rufus Τ. F. schrieb:> Warum kein Netzwerk? Da braucht man kein Parallelportgefrickel.
Das ist so eine Sache...
Der andere Rechner ist Teil eines GenRad - Testsystems aus den 80ern.
Also, so mit grüner Schrift aus schwarzem Hintergrund, und so :)
Dieser kann aber Signale vom Parallelport einlesen.
Wie müsste so eine Textdatei aussehen, die ich als "Ausdruck" an den
Parallelport sende?
Gibt es Alternativen?
Mal schauen, ob es eine auf beiden Geräten installierbare Version von
Laplink gibt? Das war für Datenübertragung per Parallelport DER Standard
über einige Jahre.
indEAS schrieb:> Du könntest mit "inpout32.dll" und Visualstudio (z.B. mit VB oder> C#) verschiedene *.exe erzeugen, die dann über Deine Batch aufgerufen> werden.
Oder ein Programm mit entsprechenden Kommandozeilenparametern. Ich würde
ihm die paar Zeilen Code auch schreiben, wenn einer meiner Rechner einen
Parallelport hätte ...
https://www-user.tu-chemnitz.de/~heha/hs/
inpout32-hs.zip
Ich habe keine Ahnung, ob die hier angeführten Dll's unter den aktuellen
Fenstern überhaupt laufen.
Sollte dies der Fall sein, so müsste Dir jemand ein Executeable
schreiben, welches z.B. folgende Aufrufparameter unterstützen sollte:
SetzePinsAnLPT LPT, Bit0, Bit1, Bit2 ... Bit6, Bit7, Strobe
Also die üblichen Verdächtigen.
Ein Aufruf in einer Batch-Datei könnte dann folgendermaßen aussehen:
SetzePinsAnLPT 1 0 1 1 1 0 0 1 1 0
"Deine erste Wunschpause"
SetzePinsAnLPT 1 0 1 1 1 0 0 1 1 1
"Deine zweite Wunschpause"
SetzePinsAnLPT 1 0 1 1 1 0 0 1 1 0
"Deine dritte Wunschpause"
SetzePinsAnLPT 1 0 1 1 1 0 1 1 1 0
"Deine vierte Wunschpause"
SetzePinsAnLPT 1 0 1 1 1 0 1 1 1 1
usw.
Bei neuerer Hardware könnte es auch ohne die Pausen gehen.
Mike schrieb:> Das ist so eine Sache...> Der andere Rechner ist Teil eines GenRad - Testsystems aus den 80ern.> Also, so mit grüner Schrift aus schwarzem Hintergrund, und so :)
Und wenn der ausfällt, dann gibt's halt keinen Ersatz? ;)
Amateur schrieb:> Ich habe keine Ahnung, ob die hier angeführten Dll's unter den> aktuellen Fenstern überhaupt laufen.
Nein, wir sind doof ... ;) Die von mir verlinkte Version funktioniert
laut Autor bis (mindestens) Windows 8.
> SetzePinsAnLPT 1 0 1 1 1 0 0 1 1 0
Oder alternativ als ein Parameter:
bla b01010101
bla h123
Georg schrieb:> du kannst also dem> Drucker an LPTx eine Textdatei schicken zum Druck.
Ach ja? Und ein per LPTx angeschlossener GDI-Würgprotokoll-Drucker
bekommt auch nur "txt"?
Wie werden dann Bilder gedruckt?
Ich kenne die Schandows und Ahnen nicht so gut, das könnt "Ihr
Klickibunti-Könner" ja so gut alleine - also: was hindert einem eine
binäre Datei an LPTx zu senden?
1
C:> COPY SOUP.BIN LPT1:
Und wenn nun diese Datei NUR 1 Byte lang ist?
Und dieses Byte genau das gefragte Bitmuster ist? (s. ASCII-Tabelle,
resp. geladene CodePage)
ODER
Die Datei ist zwar mehrere Bytes lang, diese Bytes alle gleich und von
genau dem gefragten Bitmuster?
--> mehrere 1 Byte-Dateien anlegen (soviele wie benötigte Bitmuster)
--> diese zum passenden Zeitpunkt per BATCH COPY (brrrr) die passende
Datei "drucken"
1
C:> COPY RUN.BIN LPT1:
2
C:> COPY OKDONE.BIN LPT1:
3
C:> COPY ERROSTOP.BIN LPT1:
Hindernisse?
Dass die "Peripherie" die Handshakeleitungen von LPTx: nicht "wie ein
Drucker" bedient?
(also wenn man sich LPT-Spielregeln aussucht muss man sich schon daran
halten...)
Aber deswegen ein spezielles .EXE bemühen kann doch nicht im sinne eines
Betriebssystems sein, nichtmal eines Alibi-Betriebssystems!
Man kann durchaus auch Binärdateien auf den LPT kopieren, dann aber mit
copy /b. Ohne /b hört der Kopiervorgang nach dem ersten 04 in der Datei
auf - das ist nämlich EOF...
Der Sinn eines Betriebssystems ist es übrigens, Programme zum Laufen zu
bringen. Was denn auch sonst? Und deshalb ist der Start einer speziellen
EXE für einen speziellen Zweck IMHO genau das, was ein Betriebssystem
unterstützen muss...
> copy /b. Ohne /b hört der Kopiervorgang nach dem ersten 04 in der Datei> auf - das ist nämlich EOF...
ACK dass EOF zu beachten ist, /b wird demnach schon passen... (bin da
nicht der Kenner)
Jedoch hab ich da was von ^Z in verblassender Errinnerung.
Für ^D lege ich nur unter *nics die Hand ins Feuer.
> Der Sinn eines Betriebssystems ist es übrigens, Programme zum Laufen zu> bringen.
Das ist bloss der Programmlader, ein Teil von vielen eines
Betriebssystems.
Von diesem beschränkten Modell ist die Bezeichnung "Officetauglicher
Spielelader" abgeleitet.
> Was denn auch sonst?
Ressourcen (CPU, RAM, Massenspeicher, Schnittstellen, Peripherie) zu
verwalten, Zugang dazu zu arbitrieren und den Programmen zur Verfügung
stellen; ggfs. über Systemdienste.
Also auch -und wenn nur zu Diagnosezwecke- mit einzelnen
(Daten-)Leitungen aller Schnittstellen zu wackeln.
Oder eben schlicht mal 1 Wort auf die Schnittstelle legen.
(je nach regulärem Einsatz der Ressource, sind für bestimmte Manöver
besondere Privilegien erforderlich - Arbitrierung eben)
@Frauke
>Amateur schrieb:>> Ich habe keine Ahnung, ob die hier angeführten Dll's unter den>> aktuellen Fenstern überhaupt laufen.>Nein, wir sind doof ... ;) Die von mir verlinkte Version funktioniert>laut Autor bis (mindestens) Windows 8.
Bitte sprich nur für Dich!
>> SetzePinsAnLPT 1 0 1 1 1 0 0 1 1 0>Oder alternativ als ein Parameter:>bla b01010101>bla h123
Interessant, dass Du Probleme mit dem Zählen hast!
Das angegebene Beispiel übergibt eine Zahl LPT?; 8 Binärwerte wie Du
wohl festgestellt hast; und einen Binärwert (Strobe).
bla (entsprechend dem, was Du hier abgesondert hast) gefolgt von einer
Zahl; gefolgt von einem (ev.) 8-Bit Wert; gefolgt von einem 1-Bit Wert,
unterscheidet sich wohl doch von bla b01010101. Für viele hier...
Du hast recht, da fehlte noch die Anschlussnummer. Also meinetwegen
bla 1 b01010101
bla 2 h123
Warum du Strobe per Batch explizit setzen und zurücksetzen willst (und
wie das Ganze dann überhaupt vernünftig mit ACK bzw. dem Timing generell
funktionieren soll), erschließt sich mir allerdings nicht. Ich möchte
auch noch absondern, dass du bei Strobe High und Low verwechselst.
@ Frauke
Das Strobe-Signal ist elementar.
In den meisten Fällen werden Daten bzw. Bitmuster an eine neugierige
Peripherie übergeben. Die interessiert sich brennend dafür, ob das
aktuelle Bitmuster das gleiche ist wie das vorherige, oder ob das Muster
wiederholt wurde. Üblicherweise wird dafür, je nach Absprache, die
ansteigende oder die abfallende Flanke eines Taktes verwendet.
Dazu ein einfacher Bleistift:
An einen z.B. Drucker soll der Text "paar" übergeben werden.
- Mit dem "p" ändert sich voraussichtlich der vorherige Zustand der
Übergabeschnittstelle. Also OK "p" erkannt.
- Mit dem "a" ändert sich mit Sicherheit der Zustand der Schnittstelle.
Fazit: "a" wird erkannt.
- Bei der Übergabe des zweiten "a" ändert sich aber nichts.
Fällt somit unter den Tisch - plumps.
- Die Übergabe des "r" ändert natürlich wieder den Zustand.
Fazit: Es wird ein "r" erkannt.
Das Ergebnis im obigen fall wäre also "par" - nix gut. Dabei ist es
unerheblich, ob lesbare Bitmuster im Spiel sind oder abstrakte Stati von
irgendetwas.
Natürlich könnte man einen Rhythmus aushandeln, der alle soundso viele
Zeiteinheiten von einem Datum ausgeht. Das würde aber verhindern, dass
irgendwann mal Feierabend ist oder eine - warum auch immer - Pause
eingelegt werden kann.
Sebastian S. schrieb:> @ Frauke> Das Strobe-Signal ist elementar.
Ich glaube, wir reden/schreiben ein wenig aneinander vorbei ...
Es war schon das unidirektionale "Standardprotokoll" gemeint (Datenpins
setzen, für max. 500μs Strobe auf Low (*), von der Gegenseite wird Busy
auf High, dann wieder auf Low gesetzt, dann kommt ACK (Low)). Ich wollte
lediglich darauf hinaus, dass dieser Ablauf - inkl. Berücksichtigung
eines möglichen Timeouts - vermutlich besser programmintern gesteuert
werden sollte, nicht durch das "manuelle" Setzen und Zurücksetzen von
Strobe in der Batchdatei.
Man würde dem Programm die zu sendenden Daten übergeben und (z.B.) im
Erfolgsfall 0, bei einem Fehler 1 erhalten; dies könnte anschließend
ausgewertet werden (in einer Batchdatei mit "IF ERRORLEVEL ...").
(*) Das meinte ich mit "verwechselt". Bei dir ist es 0 -> 1 -> 0.
