Ansteuern eines Bondruckers aus dem Browser

[JensKretzschmar]

Hallo leute!

Ich steh z.Z. vor einem für mich riesigen Programier Problem!

Ich habe ein schönes Kassensystem in PHP mit SQL geschieben und stehe nun vor dem Problem Clientseitig einen Epson Bondrucker mit angeschlossener Kassenschublade anzusteuern.

Das ganze sollte in Java machbar sein vermute ich... hab jetzt schon tagelang damit verbracht mich ein wenig einzufuchsen ich bekomme die ganzen dinge nicht so recht in ein schema geschweige denn in ein script

Stelle mir das ganze als java applet vor das auf dem client rechner alle freigaben bekommt (drucken usw.)

von epson gibt es einen Treiber der sich für JavaPOS bzw. UnifiedPOS ist und wohl in Java programiert ist?!

mit diesem treiber lässt sich mit dem drucker auch alles anstellen was nötig ist (schnittmesser und kassenschublade)

ich bräuchte einfach nur anregungen bzw etwas hilfe beim zusammenstellen de Javaapplets oder die aussage das das so nichts wird

vielen Dank schon mal im Vorraus!

[flashpixx]

Deine Informationen sind sehr spärlich und lassen daher nur schwer die Möglichkeit zu Dir sinnvoll zu helfen.

Meine Überlegung wäre folgende: Das das JavaApplet lokal auf dem Client ausgeführt wird, muss es dort mit dem entsprechenden Treiber kommunizieren. Die Daten müssen in das Applet vorher geladen werden z.B. via Webservice oder JDBC Zugriff auf die Datenbank. Du holst Dir die Daten über die Schnittstelle, bereitest sie druckfertig auf und gibst sie mit Hilfe des Treibers an den Drucker. Was natürlich sein kann, dass es Probleme mit Sicherheitsbeschränkungen von Java Applets gibt, weil das Applet aus dem Browser auf eine lokale Resource will.

Ich würde eher das gesamte Kassensystem als Java Applikation entwerfen, die nicht in einem Browser läuft.

Phil

[JensKretzschmar]

Vielen Dank für deine Antwort... ja ich versuche mir ja im moment noch über das schema klar zu werden wie ich das alles überhaupt hinbekomme.

Das problem ist das ich in sachen Java nicht so fit bin wie bei php html und co... Ich hab gelesen das man applets durchaus dazubringen kann auf den clientdrucker zu zu greifen. und ich hab auch schon einige java anwendungen ausprobiert um auf normalen druckern etwas zu drucken...

bei diesem lösungsansatz ist mein problem das ich das nicht in ein applett um setzen kann und das ich dann immer noch nicht weiß ob die spezifischen steuer befehle für den bondrucker auch so ohne weiteres möglich wären...

andere ansätze von denen ich schon gelesenhab schlagen vor in Java o.ä. einen Browser zu gestalten der diese druckjobs dann übernimmt und driekt clientseitig läuft.

schwieriges Thema! bin für weitere ideen / hilfestellungen sehr dankbar!

Jens

[Bubble]

Applets können die Berechtigung anfordern, mehr Rechte zu erhalten, als es die Sandbox normalerweise erlaubt. Theoretisch bis zum vollen Zugriff. Allerdings wird der Benutzer dem zustimmen müssen.

Daher kannst Du grundsätzlich schon auf Drucker und andere Geräte zugreifen.

Warum willst Du das Kassensystem aber als Webanwendung umsetzen?

[JensKretzschmar]

weil ich das ganz gut beherrsche

weil es mehrere clients werden sollen in verschiedenen filialen

weil ich dann überall darauf zugreifen kann (z.B. handy)

weil es platformunabhäniger ist

weil es günstig ist...

bis her ist nur dieser bon drucker mein hinderniss... theoretisch könnte ich den ja auch als windowsdrucker mit den entsprechenden treiber verwenden allerdings druckt er dann im grafik modus, was unheimlich langsam ist und weder kassenlade noch automatische schneide mechanissmus bedient wird.

mal abgesehen davon muss der kassierer den drucker dann auch noch auswählen und bestätigen.

[Bubble]

weil ich das ganz gut beherrsche

Dann sollten Dir auch die Limitierungen und eventuellen Probleme des gewählten Ansatzes klar sein. Ohne lokal ausgeführten Code kannst Du eben keine lokalen Drucker ansprechen (vom Drucken aus dem Webbrowser heraus einmal abgesehen).

weil es mehrere clients werden sollen in verschiedenen filialen

Geht mit anderen Lösungen auch. Nur ein zentraler Server, wenn auch einer pro Standort? Wenn der ausfällt, stehen alle Kassen still, ist das akzeptabel?

weil ich dann überall darauf zugreifen kann (z.B. handy)

Auf Kassensoftware per Mobiltelefon zugreifen?!?

weil es platformunabhäniger ist

weil es günstig ist...

Trifft auch auf andere Lösungen zu. Wobei ich bezweifle, dass es nötig ist, wirklich plattformunabhängige Kassensoftware zu verwenden.

bis her ist nur dieser bon drucker mein hinderniss...

Wie gesagt, das Problem kann man wahrscheinlich lösen, gewisse Plattformabhängigkeiten und eventuell nötige Bestätigungen durch den Benutzer können hier aber durchaus auftreten. Welcher Drucker ist es überhaupt und wie ist er angeschlossen?

[JensKretzschmar]

natürlich sind mir die probleme die das mit sich bringt klar... deshalb ersuche ich ja um hilfe

in dem kassenprogramm werden ja auch kunden und andere informationen verarbeitet, da bietet sich das schon an wenn man vor ort via handy auch kundendaten pflegen oder anschauen kann etc.

es geht um einen Epson TMT-88II mit angeschlossener kassenlade.

[Bubble]

deshalb ersuche ich ja um hilfe

Ist ja kein Problem, ich möchte nur auf gewisse Probleme hinweisen.

in dem kassenprogramm werden ja auch kunden und andere informationen verarbeitet, da bietet sich das schon an wenn man vor ort via handy auch kundendaten pflegen oder anschauen kann etc.

Das Eine muss das Andere nicht ausschließen. Eine lokal ausgeführte POS Software kann auch auf eine zentrale Kunden-DB zugreifen. Diesen Zugriff kann man auch über Webservices realisieren.

es geht um einen Epson TMT-88II mit angeschlossener kassenlade.

Müsste mir den Drucker erstmal selbst genauer ansehen. Je nachdem, wie der Drucker angeschlossen ist bzw. angesprochen werden soll, kann jedoch auf den Clients vorinstallierte oder nicht portable Software erforderlich sein.

[JensKretzschmar]

Müsste mir den Drucker erstmal selbst genauer ansehen. Je nachdem, wie der Drucker angeschlossen ist bzw. angesprochen werden soll, kann jedoch auf den Clients vorinstallierte oder nicht portable Software erforderlich sein.

Das sollte kein problem sein hab ja zugriff auf die Clients, und es ist ja nur bei denjenigen clients nötig die auch einen bon drucker verwenden. Angeschlossen ist der drucker seriell an einem com port.

Ansehen... von mir aus gerne bin ja auch berliner

[Bubble]

Das sollte kein problem sein hab ja zugriff auf die Clients, und es ist ja nur bei denjenigen clients nötig die auch einen bon drucker verwenden. Angeschlossen ist der drucker seriell an einem com port.

Welches OS verwenden eigentlich die Clients? Ist ein bestimmter Webbrowser festgelegt?

Ansehen... von mir aus gerne bin ja auch berliner

So aufdringlich war es eigentlich nicht gemeint Eher im Sinne von mal die Website vom Hersteller ansehen.

[JensKretzschmar]

hehe ja das dachte ich mir schon

os und browser sind mir wurscht haupt sache es läüft!

zum drucker gibt es alles auf epson-pos.com

[Bubble]

Ich habe mir den Drucker mal angesehen. Scheinbar hat er meist eine serielle Schnittstelle, über die er angesteuert wird.

So ohne weiteres kannst Du ihn nicht per Webanwendung ansteuern. Ich sehe die folgende Möglichkeiten für Dich:

Eine Komponente (ActiveX Control, Browsererweiterung, Javaapplet ohne Sandboxbeschränkung, ...) entwickeln, die die Hardware ansteuert oder die Schnittstelle/den Drucker im lokalen Netz freigeben und vom Server aus den jeweiligen Drucker direkt ansprechen.

[JensKretzschmar]

hmm das dachte ich mir schon soweit... mal im ernst, ich denke nicht das ich das hin bekomme wenn du mir damit helfen könntest oder es vielleicht sogar fertig machen kannst oder jemanden kennst wär ich super dankbar!

Das ganze soll im Familienbetrieb anwendung finden von daher kann ich nicht viel anbieten aber 50€ wäre ich bereit dafür zu zahlen (das entspricht dem was ich für das ganze kassensystem bekomme ) der mist ist nur, das ich das bis zum 04.11 bräuchte (± 2 Tage) denn am 08.11 ist eröffnung... :old

[flashpixx]

So ohne weiteres kannst Du ihn nicht per Webanwendung ansteuern.

Ich denke schon dass das mit Hilfe dieser Komponenten gehen würde:

4.1 Java Communications API

Java Communications API

Eine Komponente (ActiveX Control, Browsererweiterung, Javaapplet ohne Sandboxbeschränkung, ...) entwickeln, die die Hardware ansteuert oder die Schnittstelle/den Drucker im lokalen Netz freigeben und vom Server aus den jeweiligen Drucker direkt ansprechen.

Dafür muss dann aber der Server über das Netz zugreifen und eigentlich ist das eine sehr unschöne und vor allem keine sinnvolle Lösung, denn der Client ist hier die Komponente und nicht der Server, vor allem ist dann auch die Frage "wie" der Server z.B. von einem PHP Script dieses vornehmen soll

Das ganze soll im Familienbetrieb anwendung finden von daher kann ich nicht viel anbieten aber 50€ wäre ich bereit dafür zu zahlen (das entspricht dem was ich für das ganze kassensystem bekomme ) der mist ist nur, das ich das bis zum 04.11 bräuchte (± 2 Tage) denn am 08.11 ist eröffnung

Wenn ich danach gehe, dann muss ich für die gebotenen 50 Euro (brutto) ca 4 Stunden arbeiten. In 4 Stunden ein komplettes Kassensystem neu zu entwickeln, mich ggf. noch in die verschiedenen Themen einarbeiten (Treiberspezifikation u.ä.), bei einer Datenbank, die mir unbekannt ist, finde ich den Verdienst absolut unakzeptabel. Selbst die geschätzen 5 Wochen sind utopisch, um es bis dahin in den Produktiveinsatz zu bekommen. Wenn aus irgendwelchen Gründen z.B. die Transaktionen in die Datenbank schief laufen, dann trage ich später die Konsequenzen bei Fehlern in der Buchung.

Auch wenn es hart klingen mag, entweder Du musst wirklich die Zeit dafür einrechnen (obwohl ich mich auch frage, warum solche Dinge immer so kurz vor der Deadline passieren) oder Du kaufst ein fertiges System, was wohl die sinnvollste Alternative ist.

Phil

[Bubble]

Ich denke schon dass das mit Hilfe dieser Komponenten gehen würde:

Java Communications API

Gibt's nicht mehr direkt für Windows als binary. Man müsste die generische Variante verwenden und eine back-end Implementierung von RXTX : serial and parallel I/O libraries supporting Sun's CommAPI einsetzen. Wäre aber auch ausserhalb der Applet-Sandbox, d.h. wie jede andere plug-in Lösung zu betrachten.

Dafür muss dann aber der Server über das Netz zugreifen und eigentlich ist das eine sehr unschöne und vor allem keine sinnvolle Lösung, denn der Client ist hier die Komponente und nicht der Server, vor allem ist dann auch die Frage "wie" der Server z.B. von einem PHP Script dieses vornehmen soll

Ein direktes Ansprechen der Drucker vom Server aus (also ohne plug-in) ist natürlich ein (unschöner) Hack und ja, der Server muss irgendwoher über irgendeine feste ID auch "wissen" von welcher Kasse er grade aufgerufen wurde. Möglicherweise wäre es aber für ihn leichter umsetzbar. Der Teil der Serverseite zum Drucken muss dabei nicht in PHP geschrieben sein.

Ich würde eine plug-in Lösung bevorzugen, jedoch mich nicht direkt auf eine Java verwendende Variante festlegen wollen.

Bearbeitet 21. Oktober 2008 von Bubble

[Bubble]

Das ganze soll im Familienbetrieb anwendung finden von daher kann ich nicht viel anbieten aber 50€ wäre ich bereit dafür zu zahlen (das entspricht dem was ich für das ganze kassensystem bekomme )

Es ist schade, dass Du nur so wenig bekommst. Da es vermutlich für den Betrieb Deiner eigenen Familie gedacht ist, setzt Du Dich dafür ein, aber für jeden anderen wäre es einfach nur ein Auftrag.

Du wirst vermutlich kaum jemanden finden, der Dir für 50 Euro die fehlende Druckerunterstützung in einer sauberen Weise realisiert, ohne dabei eigene Zeit zu verschenken. Ausserdem müsste man einen geeigneten Drucker zum Testen beschaffen, was ebenfalls Geld kostet.

[flashpixx]

Ich würde eine plug-in Lösung bevorzugen, jedoch mich nicht direkt auf eine Java verwendende Variante festlegen wollen.

Wenn ich danach ginge würde ich dann wohl C++ mit Qt vorziehen und die Schnittstelle direkt mit passenden Libs systemspezifisch implementieren. Im Grunde führt aber das Vorhaben direkt auf ein Redesign hinaus, wobei ich dann sicherlich noch einmal das Datenbankmodell und die Design Patterns direkt mit überdenken würde.

Von der Bezahlung bzw Aufwand bis zum Produktiveinsatz würde ich von diesem Vorhaben auf den genannten Zeitraum absehen und zu einer Standardsoftware greifen

Phil

[JensKretzschmar]

Wenn ich danach gehe, dann muss ich für die gebotenen 50 Euro (brutto) ca 4 Stunden arbeiten. In 4 Stunden ein komplettes Kassensystem neu zu entwickeln, mich ggf. noch in die verschiedenen Themen einarbeiten (Treiberspezifikation u.ä.), bei einer Datenbank, die mir unbekannt ist, finde ich den Verdienst absolut unakzeptabel. Selbst die geschätzen 5 Wochen sind utopisch, um es bis dahin in den Produktiveinsatz zu bekommen. Wenn aus irgendwelchen Gründen z.B. die Transaktionen in die Datenbank schief laufen, dann trage ich später die Konsequenzen bei Fehlern in der Buchung.

Auch wenn es hart klingen mag, entweder Du musst wirklich die Zeit dafür einrechnen (obwohl ich mich auch frage, warum solche Dinge immer so kurz vor der Deadline passieren) oder Du kaufst ein fertiges System, was wohl die sinnvollste Alternative ist.

Phil

ne ne... das kassensystem ist schon fertig es geht nur um die schnittstelle zum bondrucker, also das plugin o.ä.

ich denke ich werde das einfach erst mal über den windows treiber laufen lassen. dann muss der kassierer halt den bon selbst abreißen, und die kassenlade selbst auf schließen... dann hab ich wieder zeit mir das mit dem plugin zurecht zu basteln...

[Bubble]

Im Grunde führt aber das Vorhaben direkt auf ein Redesign hinaus, wobei ich dann sicherlich noch einmal das Datenbankmodell und die Design Patterns direkt mit überdenken würde.

Er will nur eine Komponente zum Drucken, diese kommt auch ohne GUI aus, den Rest hat er nach dem, was er gesagt hat, schon. Ein komplettes Redesign des übrigen Programms will er zumindest momentan nicht.

[flashpixx]

Er will nur eine Komponente zum Drucken, diese kommt auch ohne GUI aus, den Rest hat er nach dem, was er gesagt hat, schon. Ein komplettes Redesign des übrigen Programms will er zumindest momentan nicht.

Ich sehe das im Moment so, dass wenn sich diese Komponente nur extremen Schwierigkeiten an das System anbringen lässt, dass man evtl vielen "Hacks" aus dem Weg gehen kann, wenn man ein Redesign z.b. direkt in Java machen würde.

Bei mir für diese Aussage die zentrale Fragestellung: Ist es möglich und wenn ja, welchen Aufwand muss man dafür betreiben? Wenn ich z.B. nur für diese Ansteuerung 50% des Codes überarbeiten muss, dann stellt sich mir die Frage, wie gut sind die anderen 50%.

Phil

[Bubble]

Ich sehe das im Moment so, dass wenn sich diese Komponente nur extremen Schwierigkeiten an das System anbringen lässt, dass man evtl vielen "Hacks" aus dem Weg gehen kann, wenn man ein Redesign z.b. direkt in Java machen würde.

Das ist ja nun auch völlig übertrieben. Ich halte es zwar wirklich nicht unbedingt für sinnvoll, die Oberfläche einer Kassensoftware als Webanwendung umzusetzen, aber prinzipiell lässt sich solch eine Komponente schon entwerfen und in eine Web basierende Anwendung integrieren, wenn man Kompromisse in Sachen Plattformunabhängigkeit und evtl. Browserunabhängigkeit (je nach Ansatz der Umsetzung) macht.

Und wenn schon alles Bestehede über den Haufen werfen, Redesign und neue Programmiersprache, dann würde ich mich eher für C# entscheiden.

Bei mir für diese Aussage die zentrale Fragestellung: Ist es möglich und wenn ja, welchen Aufwand muss man dafür betreiben? Wenn ich z.B. nur für diese Ansteuerung 50% des Codes überarbeiten muss, dann stellt sich mir die Frage, wie gut sind die anderen 50%.l

Du musst für die Ansteuerung vermutlich relativ wenig überarbeiten. Er muss die beim Client installierte Komponente einfach nur aufrufen und mit den zu druckenden Daten versorgen. Die Daten werden dann von der Komponente gedruckt. Dazu könnte er auch eine UnifiedPOS Umsetzung verwenden, um sich selbst möglichst wenig mit der Hardware befassen zu müssen, sofern seine Gerätehersteller die UnifiedPOS Umsetzung unterstützen.

[JensKretzschmar]

Du musst für die Ansteuerung vermutlich relativ wenig überarbeiten. Er muss die beim Client installierte Komponente einfach nur aufrufen und mit den zu druckenden Daten versorgen. Die Daten werden dann von der Komponente gedruckt. Dazu könnte er auch eine UnifiedPOS Umsetzung verwenden, um sich selbst möglichst wenig mit der Hardware befassen zu müssen, sofern seine Gerätehersteller die UnifiedPOS Umsetzung unterstützen.

Hey Bubble! Danke! Du hast erfragt worum es mir geht und es im Anschluß auch genau auf den Punkt gebracht!

Ich denke ich werd mich dann mal an das erlernen der entsprechenden programiersprache machen und für die eröffnung erst mal mit A4 Ausdrucken arbeiten. Solange bis ich die UnifiedPOS Treiber in ein Applet packen konnte.

Sollte ich beim Entwickeln auf ernste schwierigkeiten stoßen werde ich mich wieder vertrauens voll an euch wenden!

Vielen Dank noch mal für das Darstellen meiner Möglichkeiten!

:uli

[mrdr]

Hi,

ich bastel auch gerade an einer POS Anwendung, und mein TM-88III druckt schon ;-)

Und das ganze per LowTech ohne Java, sondern mit der Windows cmd.com bzw. per Batch file.

Eine php Anwendung print_bon.php

<?php


header("Content-type: application/vnd.ms-excel");

header("Content-disposition: attachment; filename=bon_to_printer.prser");

header("Pragma: no-cache");

header("Expires: 0");



// Initializes the printer (ESC @)

ECHO "^[@"; 

// Specifies a centered printing position (ESC a)1

ECHO "^[a^A"; 

// Specifies font A (ESC !)

ECHO "^[!^@"; 

ECHO "January 14, 2002 15:00^J"; 

// Prints and 3 line feeding (ESC d)+ 0x03

ECHO "^[d^C"; 

ECHO "^[!^A"; 

ECHO "^[!^A";

ECHO "TM-U210B $20.00^J"; 

ECHO "TM-U212B $22.00^J"; 

ECHO "PS-170 $17.00^J"; 

ECHO "^J";

ECHO "^[!^Q";

ECHO "TOTAL $58.00^J"; 

ECHO "^[!^@";

ECHO "------------------------------^J";

ECHO "PAID $60.00^J"; 

ECHO "CHANGE $ 2.00^J";

ECHO "^]VB^@";

ECHO "^[p^@<x";


?>[/PHP]

...erzeugt ein File bon_to_printer.prser

Die print.bat

[code]MODE COM1:38400,N,8,1 ECHO %1>COM1[/code]

...schiebt dann das File über die serielle Schnittstelle an den Drucker. Dazu muss die File.Endung prser mit der print.bat verknüpft werden.

Per Link?Bon=Text oder Formular und POST kann man der print_bon.php dabei die Druckdaten übergeben. Nach dem generieren der Druckdaten muss man noch einmal beim erscheinenden Fenster <Öffnen> anklicken und der Drucker druckt los, schneidet das Papier ab und macht die Kassenlade auf.

... soweit der Plan

Problem ist dabei, ESC Sequenzen richtig im Text unterbringen, da Sonderzeichen nicht besonders einfach zu handhaben sind, über die Systeme hinweg.

Falls Du inzwischen eine handliche Java Lösung fertig hast wäre ich auch daran interessiert. Vielleicht ist das ja noch eleganter...

[mrdr]

...die Erzeugung der Sonderzeichen ist auch kein Problem mehr

Für ESC programmiert man in PHP einfach chr(27);

So lassen sich alle beliebigen ASCII Sonderzeichen erzeugen, damit der Drucker den Bon auch abschneidet und die Kassenlade öffnet.

[JensKretzschmar]

Toll! Super das sich noch jemdand mit der Problematik beschäftigt!

Also bei mir ist der Stand der Dinge so das ich meinen Drucker an einen Programierer aus dem bekannten Kreis abgegeben habe, der meinte das hin zu bekommen. Naja seit dem hab ich allerdings nichts mehr von ihm gehört.

Vielleicht sollte ich ihn zurückfordern und deinen Lösungsweg einschlagen! das ist ja auch eine Variante auf die bisher noch niemand gekommen ist! Klasse!

Könntest du mir deine Print.bat und eventuelle andere nötige dinge zukommen lassen?

Ich wäre auch GERN bereit dir die 50€ Budget zu überlassen!

MfG Jens Kretzschmar!