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.
copy datei.txt lpt1 Schickt den Inhalt von "datei.txt" zum Parallelport.
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.
Du könntest mit "inpout32.dll" und Visualstudio (z.B. mit VB oder C#) verschiedene *.exe erzeugen, die dann über Deine Batch aufgerufen werden.
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
Oder man nehme ein EXDUL-142 (WASCO); kostet nicht viel mehr als ein Parallelport und läuft auch unter WIN7...
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.