| Ich nutze: C-Control II Unit, C164CI-ControllerBoard, C-Control II Station, CC2-Application-Board, CC2-StarterBoard, CC2-ReglerBoard, OSOPT V3.1 |
> auch wenn Du das DL-Tool entwickelt hast und damit die Internas kennst,
> aber an dieser Stelle muÃ? ich Dir wiedersprechen.
> Meine praktische Erfahrung hat gezeigt, daÃ? ich auch nach 'handischem' Einleiten des
> Hostmodes Programme per XPort übertragen kann.
Nein. Das geht definitiv nicht. Es werden über Socks Datenblöcke mit mehr als 1024 Byte gesendet,
da hier ein anderes, von mir entwickletes Protokoll, verwendet wird.
Die CC2 kann bei händischen Einleiten auch nur erkannt werden, wenn die Baudrate des XPorts
auf 19.200 steht.
> So verwende ich zum �bertragen der Makros zum eDIP Dein beigefügtes Programm
> MakroLoad1.
> Da dieses ja nicht mit quit 256 beendet wird, würde es ja bedeuten, da� ich
> mein 'richtiges' Programm dann nur noch per direkter RS232 Verbindung
> übertragen könnte.
> Aber auch diese anschlieÃ?ende Ã?bertragung funktioniert per XPort und handisch
> eingeleitetem Hostmode.
Ich glaube, Du everwendest garnicht die Netzwerkfunktionalität der V2.3Beta des DL-Tools,
sondern den COM-Port-Redirektor.
Somit nutzt Du die RS232-Funktionalität des DL-Tools. Du hast hier einen COM-Port
angegeben, und keine IP.
Hier muÃ? aber der XPort generell mit 19.200Baud laufen. Ebenso Deine gesamte Kommunikation.
Im DL-Tool hast Du dann ebenfalls 19.200Baud konfiguriert.
Bei diesem Vorgehen besteht die erhöhte Gefahr von Datenfehlern oder Verbindungsabbrüchen,
da hier ohne Protokoll geladen wird.
Zudem dauert das Laden aufgrund der hohen Latenzzeiten im Netzwerk
gegenüber RS232 so deutlich länger.
Bei Laden über eine Socks-Verbindung wird ein eigenes Protokoll genutzt, welches erst
ab OSOPT V3.1b2 enhalten ist. Die Nutzdatengrö�e beträgt hier pro Datenblock 1024Byte.
Dazu kommen noch Steuerdaten, sowie Prüfsummen.
Dadurch darf es zu Datenfehlern, kommen, ohne daÃ? das Laden abgebrochen wird.
Das macht in jedem Fall ein einen entsprechend groÃ?en Empfangspuffer erforderlich.
Und dieser wird derzeit noch im Programm definiert.
Auch ist das Laden so viel schneller, da kein Echo zurückgesendet wird, sondern
Ein ACK mit Prüfsummen. Und das nur alle 1024Byte Nutzdaten.
�ber die Standardladefunktion werden 32Byte gesendet, die Daten als Echo zurückgesendet und
erst anschlie�end die nächsten 32Byte auf den Weg geschickt.
Für das Laden in einem lokalen Netzwerk ist das noch erträglich.
Versuch das aber mal mittels Remote-Verbindung zu einem Kunden ...
Das Protokoll ist so ausgelegt, da� auch bei hohen Latenzzeiten ein zügiges und sicheres
Laden möglich ist.
MfG André H.
Antworten bitte nur ins Forum!
Fragen per EMail auf Forum-Postings werden nicht beantwortet!
Das macht meine Heizung gerade
Antwort schreiben
Antworten:
Re: XPort und DL-Tool (von Heiko - 3.01.2010 13:23)Re: XPort und DL-Tool (von André H. - 3.01.2010 17:08)Re: XPort und DL-Tool (von Heiko - 3.01.2010 17:37)