Hallo, ich habe ein Projekt in der Schule laufen bei dem ich eine CNC-Maschine über einen Microcontroller steuere, was sehr gut funktioniert. Der Microcontroller wird allerdings wiederum vum Delphi geteuert, denn in Delphi rechne ich alle wichtigen Înformationen aus und sende sie dann weiter an Microcontroller. Das Senden erfolg auch ohne weidere Probleme(SENDBYTE), (ich verwenden in delphi die Port.dll). So und jetzt kommt das Problem : Damit keine größere Warte Zeiten entstehen, habe ich einfach in einer whileSchleife den READBYTE eingesetzt mit einem delay von 500ms, nach kurzen zeiten bekommt er noch was zurück, doch ab einen gewissenen Distanz schiesst Delphi den opencom ab oder macht sonst was, so dass eng den FERTIG von Micorcontrolelr nicht mehr kann empfangen. Es liegt nicht am microcontroller, der empfangt und sendet wie er soll! Hab auch schon Probiert mit anderen Methoden, doch bis jetzt ohne erfolg! z.b. nicht mit while sondern in einem Timer .... repeat until ... Ich bitte um Hilfe, DANK p.s. : bei unverstaendnissen meiner Aussage, einfach nachfragen :)
hallo, Zeig doch erstmal deinen Delphi-Code, und am Besten gleich noch den (relevanten Teil vom) Mikrocontroller-Code. Nach deiner Beschreibung gehe ich aber mal davon aus dass du ohne Plausibilitätskontrolle arbeitest? Bei einer CNC-Steuerung würde ich unbedingt bei jedem Befehl per RS232 eine Checksumme mitschicken, damit der Empfänger einen allfälligen Fehler mitbekommt und das Datenpaket nochmals vom Sender anfordern kann. Es wäre möglich dass bei deinen Tests irgendwann mal ein Byte verloren geht oder sich ein Geisterbyte einschleicht, dann wird deine Auswertung wohl schon überfordert sein. (Reine Vermutung da ich den Code ja nicht anschauen konnte!) Die Zeit, welche für die Plausibilitätskontrolle draufgeht, wirst du ja wahrscheinlich eh haben, da vermutlich die Maschine das langsamste Glied im Informationsfluss darstellt...
>doch ab einen gewissenen Distanz schiesst Delphi den opencom ab
Wie ist das zu verstehen? Meinst du mit "Distanz" die Kabellänge oder
eine längere Wartepause? Was meinst du mit "schiesst Delphi den opencom
ab"?
Ist die Schnittstelle noch geöffnet, wenn der Fehler auftritt oder
nicht? Bei geschlossener Schnittstelle liegt der Fehler bei deinem
Delphi-Programm. Delphi schiesst sicher nicht von selbst die
Schnittstelle ab, das passiert nur dann, wenn dein Sourcecode das
irgendwo anordnet. Es ist deine Aufgabe als Programmierer, die korrekte
Handhabung der Schnittstelle sicherzustellen. Bau doch eine zusätzliche
Sicherheitsabfrage in deine Sende- bzw- Empfangsroutinen ein. Teste VOR
jedem Zugriff auf die Schnittstelle, ob diese geschlossen oder geöffnet
ist und gib eine entsprechende Fehlermeldung aus, wenn es Probleme gibt.
Weitere mögliche Fehlerquelle:
Ist die Schnittstelle im PC, die du verwendest, eine echte serielle
Schnittstelle mit UART oder bloss ein USB-RS232-Adapter? Bei einem
USB-Adapter kann es sein, dass der in "Suspend Mode" geht, wenn er
längere Zeit nichts zu tun hat. Der Suspend-Mode wird wiederum von
Windows selber ausgelöst, in diesem Fall musst du die entsprechenden
Einstellungen in deinem Betriebssystem ändern. Siehe dazu den
angehängten Text.
Wozu braucht man eine "port.dll", wenn eine serielle Schnittstelle verwendet wird?
Rufus Τ. Firefly schrieb: > Wozu braucht man eine "port.dll", wenn eine serielle Schnittstelle > verwendet wird? das habe ich mich auch gefragt, aber es steht ja nirgends da das er die Serielle schnittstelle verwendet. Keine ahnung auf was SENDBYTE geht.
Peter schrieb: > aber es steht ja nirgends da das er die > Serielle schnittstelle verwendet Wie interpretierst Du dann das hier? > doch ab einen gewissenen Distanz schiesst Delphi den opencom
Hallo,
Ja ich benutzte eine richtige Serielle Schnittstelle und keine USB to
Seriel Adabter!
Also es ist so dass ich Kordinaten zu dem Microcontroller sende ... und
dann läuft mein delphi in eine whiile schleife um immerwiederabzufragen
ob der Microcontroller fertig ist mir dennen Kordinaten, um sofirt die
naecksten zu senden !
==========
//senden
=========
======================
// empfangen
Temp := readbyte;
while chr(Temp) <> '*' do
begin
delay(500); //damit eer nicht dauernt duerchläuft eine kleine
paus
Temp := readbyte;
end;
=========================
so wenn ich jetzt kleiner Schritte fahre, dass heisst er ist nicht so
lange in der Schleife (dempfangen) funktioniert es ... fals länger
Kordinaten gesenden wurden, bekommt er keinen * obwohl microcontoller
einen senden ... ich GLAUBE dass in eine gewissenen Zeit den com
geschlossen wird ... dass ich das einzige was passen würde, doch
allerdings ist dat schwer forstellbar , das ist wohl war ...
und warum brauch man eine Port.dll ??? Wie möchte man sont mit delphi etwas an den com schnittstelle senden ????
lies dir doch erstmal genau durch wie readbyte arbeitet, meine vermutung ist das er wartet bis ein zeichen da ist, du musst nicht selber danach warten. So ist es zumindest in den meisten programmiersprachen wenn man nicht auf den "nichtblockierendnen" modus umschaltet.
david schrieb: > Wie möchte man sont mit delphi etwas an den com schnittstelle senden > ???? windows bietet dafür eine API an, die Port.dll braucht man nur wenn man direkt auf die IO-Adresse zugreifen will. Das ist hier aber überhaupt nicht notwendig
Hab noch nie mit API gearbeitet .. desswegen keine ahnung :S OPENCOM Parameter: Zeichenkette als nullterminiereter String Öffnen der seriellen Schnittstelle Rückgabe: Bei Fehler 0. SENDBYTE Parameter: Ein Byte (0..255) Senden eines Bytes über die serielle Schnittstelle. Diese muß zuvor mit OpenCom geöffnet worden sein. READBYTE Parameter: keine Lesen eines Bytes von der seriellen Schnittstelle. Diese muß zuvor mit OpenCom geöffnet worden sein. Rückgabewert: -1 bei Fehler, sonst das empfangene Byte
david schrieb: > READBYTE > Parameter: keine > Lesen eines Bytes von der seriellen Schnittstelle. Diese muß zuvor mit > OpenCom geöffnet worden sein. > Rückgabewert: -1 bei Fehler, sonst das empfangene Byte da muss es doch noch mehr doku geben, wie werden timeouts behandelt? Kann es sein das du RSCOM-DLL verwendest und nicht port.dll?
mach doch einfach mal ein test while TRUE do begin Temp := readbyte; end sende aber nicht an die Schnittstelle. Dann sollte das programm eigentlich keine CPU zeit brauchen -> readbyte warten auf daten. Wenn dein Programm docht CPU-zeit braucht dann blockiert der aufruf von readbyte nicht -> doku genau lesen wie es dann richtig geht.
ich benutze die port.dll while TRUE ... was aht es mit dem true aufsich .... was soll true sein ??
true ist ein boolscher Ausdruck, wie '1' in C.
API Call:
function CreatePortHandle(PortID: string; PortNumber: cardinal):
THandle;
begin { CreatePortHandle }
PortID := '\\.\' + UpperCase(PortID) + IntToStr(PortNumber);
Result := CreateFile(PChar(PortID), // name
GENERIC_READ or GENERIC_WRITE, // access
attributes
0, // no sharing
nil, // no security
OPEN_EXISTING, // creation action
FILE_ATTRIBUTE_NORMAL, // attributes
0); // no template
end; { CreatePortHandle }
wenn ich diese Funktion einbinde... und wie oben angegeben whiel TRUE do abfrage ich das automatisch ne abfrag für den COM ? das true muss doch mit irgendetwas in verbindung seten Z.B: while Test = true do .... und wie kann ich mit dieser funktion etwas senden und empfangen ?
david schrieb: > das true muss doch > mit irgendetwas in verbindung seten Z.B: while Test = true do ich glaube du solltet dich erstmal noch ein wenig mit den grundlagen von Delphi beschäftigen. wenn das geht: var x: Boolean; x := true; if x then println("test"); warum sollte dann if true then println("test"); nicht auch gehen. Es wird bei if geprüft ob der wert wahr ist. Und true ist nun mal wahr. Man könnte auch schreiben if true=true then println("test"); oder if false=false then println("test"); oder if true<>false then println("test"); http://www.delphipraxis.net/57121-ueber-den-umgang-mit-boolean.html (sind bestimmt noch fehler drin, mein delphi zeit ist leider schon viele jahre her, da heiß es noch pascal)
ja ok ... also mit den grundlagen von delphi kennen ich mich schon ein wenig aus ... hab nur nicht den sinn in dieser schleife gesehn , well du bleibs ja immer in dieser schleife ... aber ja ich sage dir trotzdem vielen vielen dank für deine(eure) Hilfe, sehr net. mfg david
david schrieb: > hab nur nicht den sinn in dieser schleife gesehn , well du > bleibs ja immer in dieser schleife ... genau das war der sinn, ich wollte damit nur ermittln ob die Readbyte auf daten wartet oder ob es immer sofort zurückkehrt. Normalerweise wartet es auf das nächste byte also brauchst du nicht selber ein sleep danach zu machen. Ein sleep in einem Programm ist oft nur der versucht einen Fehler zu beheben der eigentlich in dem Programm ablauf selber liegt.
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.