Announcement: there is an English version of this forum on 
Hallo Forengemeinde, ja, habe weitere Schwierigkeiten gewisse Sachen umzusetzen. Es geht weiter um meine Isel-CNC. Kann nun mit der Isel zumindest soweit kommunizieren, dass sie mir z.B. den Status mitteilt. Habe einen Screenshoot vom Programmausschnitt, den es betrifft und das Formular angehängt. Folgendes Problem: mit dem Button 'Status' sende ich eine Sequenz an die Isel, und diese gibt mir dann das im oberen Fenster zurück. Beim drücken des Buttons 'Übersetzen' werden CR zu CR/LF umgewandelt, so das die Meldung sauber erscheint. Siehe rechtes unteres Bild/Fenster. Ich möchte aber natürlich, dass dies in einem Rutsch passiert. Also Button 'Status' drücken, und in einem Textfenster erscheint die Meldung korrekt. Es ist aber so, dass die Antwort, bis die Isel diese übertragen hat ein paar Sekunden dauert, weil sie z.B. den Speicher und Weiteres erst checkt. und man erst auf die Vollständigkeit der Meldung warten muss. Die Meldung baut sich nach und nach auf. Nun habe ich hier ein Brett vor dem Kopf, wie ich das realisieren kann. Habe einen Button mit übersetzen, der aber soll weg, und die übersetzung automatisch erfolgen. wer kann / möchte mir helfen?
Angehängte Dateien:
-
VB_Statusnzeige.PNG
30 KB
Warten bis alles da ist, erst dann filtern und darstellen.
Franko S. schrieb: > Warten bis alles da ist, erst dann filtern und darstellen. Und woher kommt dieses Feedback?
Du müsstest im Ereignis der mscomm1 das Ende des Empfangsbuffers auswerten (endet auf check finished) und dann die Übersetzung anstossen
Christian H. schrieb: > Du müsstest im Ereignis der mscomm1 das Ende des Empfangsbuffers > auswerten (endet auf check finished) und dann die Übersetzung anstossen Genau das ist die Frage, wie ich dies bewerkstellige. Da steh ich auf dem Schlauch. Ich könnte auf die Meldungslänge z.B. >315 reagieren, oder eben wirklich auf 'FINISHED'. Aber wo baue ich das ein? Im ...OnComm()? - funktioniert das nicht. Diese wird anscheinen nur bei Ankunft eines Zeichen aufgerufen. Nicht einmal eine MessageBox öffnet sich hier. Auch eine If-Anweisung mit Meldungskorrektur wird hier ignoriert. Auch in der aufrufenden Funktion / Procedure klappt das nicht. HIer habe ich das Ablauf-Verständniss-Problem.
Hallo Thomas S., Thomas S. schrieb: > Im ...OnComm()? - funktioniert das nicht. Diese wird anscheinen nur bei > Ankunft eines Zeichen aufgerufen. Das ist nur Deine Vermutung. Du musst der Schnittstelle bei der Arbeit zusehen! Statt Me.Text1=M.Text1 + InBuffer besser noch ein Zeichen für Debugging einsetzen: Me.Text1=M.Text1 + InBuffer + "/" Dann siehst Du genau, in wieviel Portionen die Antwort ankommt. Ich glaube nicht, dass Dein Gerät die Antwort byteweise liefert! > Nicht einmal eine MessageBox öffnet Das wäre der totale Gau und ist vollkommen sinnlos. Was ist, wenn Du nur ankommende Daten verarbeiten willst? Für die Anzeige von Daten bist Du verantwortlich. Wenn Deine Gerätedokumentation das nicht hergibt, musst Du für jeden Typ von Sende-Anfrage die Antwort protokollieren. Dann musst Du Dir überlegen, wie Du die Antworten separierst. Status-Anfragen sind gerne mehrzeilig, also kannst Du einen typischen Endebezeichner wie CR LF nicht als Endemarkierung verwenden. Die On-Com-Methode sollte wissen, wonach du vorher gefragt hast und dementsprechend reagieren. In einem Fall prüft sie das "Check Finished" am Ende der Nachricht, im anderen Fall reichen vielleicht das Prüfen der Endemarkierung CR LF. Wenn CR LF am Anfang auftauchen, ist wohl etwas schiefgelaufen. Hast Du "empfang" und "inBuffer" auch mit DIM deklariert?
Fehlerkorrektur:
>Status-Anfragen sind gerne mehrzeilig,
muss heißen
" Antworten auf Status-Anfragen sind gerne mehrzeilig,"
Ich hatte mal ein ähnliches Problem mit einem Hand-Scanner. Die Aufgabe damals war, eine eingescannte EAN anschließend in einer DB zu suchen und bei Fund in eine Gridbox einzutragen. Da hatte ich den Scanner auch auf das CR als Endezeichen eingestellt und einen HotKey (halt CR) definiert. So ein CR bzw. RETURN reagiert ja bei einzeiligen Editfeldern mit einem Klingelton (Bing). Jedenfalls hatte das damals einwandfrei funtkioniert. Man muß nur darauf achten, daß das Editfeld nach Auslesen den Focus behält. Wenn so ein Editfeld halt stört, kann man es auch unsichtbar für den User machen. Vielleicht kannst du hier ein ähnliches bzw. leicht abgewandeltes Verfahren anwenden.
Thomas S. schrieb: > Im ...OnComm()? - funktioniert das nicht. Doch natürlich. Wenn man's richtig machen würde, würde das schon funktionieren. Die Grundstruktur dessen, was nötig ist, hast du ja hier sogar bereits eingebaut (sinnloserweise sogar gleich doppelt...), aber ich kann hier keinerlei Ansatz zur Auswertung bezüglich des Nachrichtenendes entdecken. > Diese wird anscheinen nur bei > Ankunft eines Zeichen aufgerufen. Nein, die wird immer dann aufgerufen, wenn einerseits ungelesene Zeichen im Puffer des "COM-Ports" liegen, und andererseits das OS gerade Zeit hat, den Task deiner Anwendung laufen zu lassen.
Angehängte Dateien:
-
Positionsabfrage.PNG
25 KB
VB macht mich wahnsinnig. Ich habe weiterhin ein Verständnissproblem Habe nun das geschaft, dass die Statusmeldung nun sauber ist, da ich den Tausch CR = CR/LF sofort in OnComm mache. Nun ein Schritt weiter, möchte ich die aktuelle Position der CNC in Erfahrung bringen. Dazu sende ich :@0P + Chr(13) Die Isel antwortet nun mit insgesamt 19 Bytes. Da die CNC sich noch nicht bewegt hat, ist das Ergebnis: 0000000000000000000 Das möcht ich nun im Textfeld stehen haben. Habe nun den Code, mit allenmöglichen Änderungen versucht. Aber anscheinend ist das event 'button' schon wieder raus, oder was weiß ich. Habe es mit einer Variablen: empfang versucht. Empfang am Funktionsanfang gelöscht, usw. Die Routine ist anscheinend zu schnell, und die Isel zu langsam mit 9600. Jedes Komando, wenn die CNC es versteht wird mit '0' quitiert. Ansonsten kommt ne Zahl >0 als Fehlercode. Bitte erklärt mir, wo meine Denk-Fehler hier sind,
Thomas S. schrieb: > VB macht mich wahnsinnig. Nein, das hat mit VB nichts zu tun. Du kannst einfach nur nicht programmieren. Du verstehst ganz offensichtlich nicht, was du da tust. Das würdest du in jeder anderen Sprache genausowenig begreifen. > Bitte erklärt mir, wo meine Denk-Fehler hier sind, Dein grundsätzlicher Denk-Fehler ist, daß man Programmieren erklären könnte. Nein, das kann man nur lernen. Indem man die Sache wirklich durchdenkt und überlegt, was da passiert und wie man das Geschehen in die richtige Richtung lenkt. Hier ist das Problem, dass der Code in OnComm überhaupt keinen Kontext hat. Er weiß also nicht, was überhaupt die Frage war, die irgendwo anders gestellt wurde, soll aber die Antwort sinnvoll aufarbeiten. Das kann nicht funktionieren. Schon deshalb nicht, weil die Antworten halt verschieden sein können (und es offensichtlich auch sind). In erster Näherung musst du also einen Mechanismus schaffen, der dem Code in OnComm sagt, was er da jetzt als Eingangsdaten zu erwarten hat. Dann mußt du in OnComm eine Verzweigung schaffen. die die unterschiedlichen zu erwartenden Eingangsströme auch unterschiedlich behandelt. Und (viele Programmierstunden später) kannst du dann noch versuchen, die Gemeinsamkeiten der verschiedenen Aktionen zu einem gemeinsamen PROTOKOLL zusammen zu fassen, welches der OnComm-Handler zunächst mal einheitlich behandeln könnte. Erst wenn dieser Teil der gundsätzlichen Behandlung des Informationsaustauschs abgehandelt ist (also im Minimum: Erkennung von Nachrichten-Anfang/Ende), muss dann verzweigt werden. Und, wie schon gesagt, das hat alles mit der Sprache nix zu tun. Das Problem wäre in jeder anderen Sprache gundsätzlich ganz genauso zu lösen.
Peter M. schrieb: > Wenn CR LF am Anfang auftauchen, ist wohl etwas schiefgelaufen. Dies sendet die Isel so. Auch im Terminal kommt der Aufbau so. Ob S. schrieb: > Hier ist das Problem, dass der Code in OnComm überhaupt keinen Kontext > hat. Er weiß also nicht, was überhaupt die Frage war, die irgendwo > anders gestellt wurde, soll aber die Antwort sinnvoll aufarbeiten. So viel kann die CNC nicht. Ich schicke ihr ein Komando, und im besten Fall antwortet die CNC mit '0', ansonsten kommt ein Fehler mit einer Nummer zwischen 1 und 99. Ich lösche den Puffer 'empfang', und erwarte in der aufrufenden Procedure zum Button 'Position', dass hier dann in 'empfang' die Position mit länge 19 steht. Aber wie oben schon durch, also benötige ich etwas, ds solngae hier wartet, bis die 19 Bytes dann da sind.
Thomas S. schrieb: > So viel kann die CNC nicht. > Ich schicke ihr ein Komando, und im besten Fall antwortet die CNC mit > '0', ansonsten kommt ein Fehler mit einer Nummer zwischen 1 und 99. Du begreifst es wohl wirklich nicht... Es ist überhaupt nicht Aufgabe der CNC, sich mit den Befindlichkeiteten des Clients zu beschäftigen. Der (und nicht die CNC) muß sich merken, was er die CNC zuletzt gefragt hat und der (und nicht die CNC) muss auswerten, was da als Antwort auf die Frage zurück kam. Geht halt deutlich besser, wenn der Client sich an die gestellte Frage erinnert, wenn die Antwort der CNC darauf eingeht... Mein Gott. Sowas ist dermaßen logisch, dass ich einfach nicht begreifen kann, dass irgendjemandem das nicht sofort selber klar ist.
Beitrag #7719437 wurde vom Autor gelöscht.
Ob S. schrieb: > Du begreifst es wohl wirklich nicht... > > Es ist überhaupt nicht Aufgabe der CNC, sich mit den Befindlichkeiteten > des Clients zu beschäftigen. Das sage ich ja nicht. Ich weiß, das min Programm drauf reagieren muss. Ist mir schon klar. Und ich kriege ja auch das Feedback von ihr. Lassen wir es. Anscheinend kann ich es nicht vermitteln wo es klemmt. Guten Tag noch.
Hallo Thomas S., Thomas S. schrieb: > Aber wo baue ich das ein? > Im ...OnComm()? - funktioniert das nicht. Diese wird anscheinen nur bei Natürlich. Du erhältst ein Zeichen, hängst es an Deinen Ergebnisstring an und prüfst, ob die ISEL-Rückmeldung vollständig ist. Wenn ja, verarbeitest Du die Rückmeldung, also den Ergebnisstring, wenn nein, machst Du gar nichts und die Prozedur des OnComm-Event wird beendet. Das ist deswegen möglich, weil das OnComm-Event völlig ohne Dein Zutun von Excel aufgerufen wird, sobald ein Byte im Empfangspuffer der Schnittstelle liegt. Es hängt nun davon ab, wie Du im Event prüfst, ob die Rückmeldung Deiner Schnittstelle komplett ist. Du könntest prüfen, ob der String "empfang" auf 19 Stellen Länge angewachsen ist oder ob der String auf CR LF endet. Erst wenn das Ergebnis der Schnittstelle komplett ist, beginnt die Nachbearbeitung und die Verarbeitung des Ergebnisses. Nachbearbeitung bedeutet z.B., ein CR LF am Anfang des Strings "empfang" zu entfernen. Diese Entfernung gehört in die OnComm-Logik, aber nicht in eine Extra-Prozedur wie Deine Command6-Klick, die mit Klick auf eine Schaltfläche manuell gestartet wird, schließlich soll Dein Programm das ohne Dein explizites Zutun von alleine machen. Dann verarbeitest Du das Ergebnis. Du schreibst es vielleicht in eine Textbox in Dein Formular. Bei einem Datalogger würdest Du das Ergebnis in eine Zahl umwandeln, und z.B. in einer Excel-Spalte protokollieren oder vielleicht in eine Datei schreiben.
:
Bearbeitet durch User
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.