Zitat von
Computerbabalulu:
Hallo ihr lieben.
Es gibt ein Problem bei dem ich grade nicht weiter komme. :gruebel:
Ich muss aus meiner Anwenung heraus (Delphi 2007), über den
COM Port
einen Barcode Scanner umprogrammieren von EAN auf Codabar.
Bezüglich der Scannerprogrammierung habe ich sogar die Beschreibung,
welche Befehle an den Scanner gesendet werden müssen (komplette Beschreibung im Anhang):
....
Nur stehe ich hier grade etwas auf dem Schlauch. Ich hab keine Idee wie ich das im Programm umsetzen könnte.
Als Componenten für die kommunikation hätte ich Async Professional installiert.
Hat von euch jemand vielleicht soetwas schon einmal gemacht und kann mich wieder auf den Weg bringen :wall:
Gruß Baba
Hallo,
ich kann dir hier nur beschreiben, wie ich bei ähnlichen Projekten verfahre, vielleicht kannst du für dich was draus entnehmen. Eine solche Kommunikation ist nicht ganz trivial, aber in manchen Punkten kann man den nötigen Umfang einschränken.
1. Die Kommunikation verläuft immer nach dem Schema Befehl senden - Warten auf Antwort - Antwort analysieren. Die
COM-Port-Komponente muss also nach aussen nur eine einzige Arbeitsfunktion zur Verfügung stellen, die heisst bei mir RequestAnswer, exakt müsste sie heissen SendCommandAndGetAnswer. Natürlich kommt noch eine Menge Verwaltungsarbeit dazu zum Initialisieren, Fehlerbehandlung usw.
2. Die Komponente TStation ist das Modell der angesprochenen Messstationen. Hier ist definiert, wie die Station auf Befehle reagiert (Statusänderungen) und welche Antworten sie zurücksendet - sozusagen der semantische Teil des Pflichtenhefts. Hier werden insbesondere die empfangenen Antworten logisch ausgewertet und der Zustand der Sation entsprechend geändert (bei Fehler z.B. auf "Offline").
3. Die Komponente IPRecord definiert die einzelnen Messages, der syntaktische Teil des Pflichtenhefts. Die Funktion BuildStatusRequest z.B. liefert den String zurück, der an eine Station zu senden ist, um den Status zu prüfen. Ebenso werden die Antworten dekodiert, d.h. alle Befehlsdefinitionen und alle Formatierungen von Zahlen usw. sind hier definiert. Muss man nicht so machen, ich habe das aber der Übersichtlichkeit in eine eigene
Unit ausgelagert.
4. Die Komponente Transaction stellt die übergelagerten Abläufe auf Benutzereingaben usw. zur Verfügung. Die TransAction ist zunächst abstrakt formuliert, davon wird jede konkrete Transaction abgeleitet. Die Transaction GetStatus besteht bloss aus den Schritten Befehl senden und Antwort empfangen, das Starten einer Messung mit Anlegen von Dateien hat natürlich mehr Schritte.
5. Die Komponente TConnection stellt die eigentliche Verbindung zur Verfügung, diese kann
COM oder Sockets oder USB sein und mit oder ohne Threads. Unbedingt notwendig sind Threads nicht, die Software kann in der Zeit, in der sie Befehl und Antwort abwickelt, sowieso nichts sinnvolles tun, auch die meisten Usereingaben sind nicht zulässig. Fertige Komponenten für
COM verwende ich übrigens nicht.
Für einen Befehl an die Station ist also eine neue Transaction abzuleiten und in IPRecord sind die Strings dafür zu definieren. Drückt z.B. der User bei einer "Offline"-Station auf "Connect", erzeugt die Station eine Transaction "StatusRequest" und startet sie. Läuft die Transaction ohne Fehler durch, ändert sich der Stationsstatus auf "Online" und weitere Statusdaten werden angezeigt.
Ein paar Schnipsel:
Delphi-Quellcode:
type
TBPMTransAction = class (TObject)
TAStation : TBPMStation;
TAConnection : TBPMConnection;
TAString : ShortString;
TADecodedAnswer : TBPLMessage;
TASuccess : boolean;
TAFinished : boolean;
TAWaiting : boolean;
TAStepNo : integer;
TAErrorRepeat : integer;
TASuccessRepeat : integer;
constructor Create (OStation : TBPMStation);
destructor Destroy; override;
procedure Cancel (errortxt : ShortString);
procedure NoSuchStep;
procedure StepDone;
{ a step may start a long operation or do it directly.
the message WM_TACONTINUE loops to DoNextStep
the message WM_TAFINISHED loops back to the station loop }
procedure Step1; virtual;
procedure Step2; virtual;
procedure Step3; virtual;
procedure Step4; virtual;
procedure Step5; virtual;
procedure Step6; virtual;
procedure Step7; virtual;
procedure Step8; virtual;
procedure DoNextStep;
procedure Start;
procedure AllDone;
end;
TBPMTransAction_GetStatus = class (TBPMTransAction)
constructor Create (OStation : TBPMStation);
procedure Step1; override; { send status request }
procedure Step2; override; { receive status }
end;
{**************}
{ GetStatus }
constructor TBPMTransAction_GetStatus.Create (OStation : TBPMStation);
begin
inherited Create (OStation);
TAErrorRepeat := 2;
TASuccessRepeat := 1;
end;
{ send StatusRequest }
procedure TBPMTransAction_GetStatus.Step1;
begin
BPLSndRcvRecord.Build_StatusRequest (TAStation.NodeNo);
TAString := BPLSndRcvRecord.GetRequestMessage;
TAConnection.PutSendString (TAString);
TASuccess := TAConnection.RequestAnswer; { lengthy task }
if TASuccess then StepDone else
begin
TAStation.Process_StatusNoAnswer;
AllDone;
end;
end;
{ send StatusRequest }
procedure TBPMTransAction_GetStatus.Step2;
begin
TAConnection.GetReceivedString (TAString);
BPLSndRcvRecord.PutAnswerMessage (TAString);
TASuccess := BPLSndRcvRecord.VerifyAnswerType;
if TASuccess then TASuccess := BPLSndRcvRecord.DecodeAnswer;
if TASuccess then TADecodedAnswer := BPLSndRcvRecord.GetDecodedMessage;
if TASuccess then
TASuccess := TAStation.Process_StatusAnswer;
AllDone;
end;
Natürlich kann man alles ganz anders einteilen und überhaupt alles anders machen, dazu bekommst du sicher noch jede Menge Meinungen. Ist aber mal eine mögliches Gerüst.
Gruss Reinhard
PS du kannst sicher manches einfacher rein linear abarbeiten - die obige Software soll bis zu 64 Messstationen verwalten und jederzeit Eingriffe zulassen, aber notfalls auch wochenlang allein im Hintergrund arbeiten, das ist bei dir ja nicht nötig.