Eingang abfragen über Ethernet

International Deutsch
1

Hey Ho an alle,

seit mehreren Tagen durchforste ich das Internet habe bisher aber noch keine Lösung gefunden :frowning:

... also folgende Situation:

Ich habe zwar zwei Controlinos (MAGA und Maxi) aber die kann man mit einem Arduino Mega un einem Arduino UNO gleichsetzen. Der vorteil ist nur, dass die I/Os direkt mit 24V arbeiten können. Des weiteren ist direkt ein w5100 Ethernetshield eingebaut. Aber wie gesagt is das mit den genannten Arduinos gleich zu setzen.

In dem Projekt geht es darum die alte Schütz und Klappertechnick eines Beladehandlings abzulösen.

Für den "Arduino MEGA" Habe ich bereits Skatch geschrieben. Es ist eine Schrittkette, die den ganzen Ablauf bei einem Beladeprozess (Im Automatikbetrieb) übermint. Auch nahe zu alle Sensoren und Aktoren sind direkt am Mega Angeschlossen.

Der "Arduino UNO" soll in einem Hand-Bedienpult verbaut werden. An diesem werden sämtliche Schalter, Drucktaster und entsprechende Signal-leuchten für die Bedienung angeschlossen.

Mann kann also sagen der "Arduino MEGA" ist mein Client und der "Arduino UNO" ist mein Server.

Die erste Abfrage im Skatch des MEGA ist, welche Betriebsart gewählt ist.
Hier nur kurz zur Veranschaulichung:

void loop() {

if (!digitalRead(A10)) {
Handbetrieb();
} else {
Automatikbetrieb();
}

Nun darf ich aber nicht wie hier den Pin A10 des MEGA nehmen, sondern dehn des UNO.
Der MEGA muss also über Ethernet fragen, ob der zustand an Pin A10 des UNO HIGH oder LOW ist.

Desweiteren sollte der MEGA dem UNO befehlen können einen Ausgang HIGH oder LOW zu setzen (z.B. für eine Signal-leuchte).

Für einen guten Ansatz währe ich echt dankbar.
LG

2

Da musst Du zwischen beiden kommunizieren, z.B. über UDP (fire and forget) oder TCP (mehr Overhead aber die Zustellung wird sichergestellt, wenn eine Verbindung besteht).
Für UDP habe ich da mal eine Prinzipstudie zwischen 2 NodeMcu gemacht. Das Prinzip ist aber das Gleiche.

Gruß Tommy

3

Danke schon mal für die Hilfe.
Ganz durchblickt habe ich das Thema noch nicht, aber ich hoffe das mein Ansatz passt. Oder???

Hier der Server

//Server
#include <Ethernet.h>
#include <SPI.h>



byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };

IPAddress ip_client(192, 168, 1, 200);           // IP Adresse des Client
IPAddress ip_server(192, 168, 1, 201);           // IP Adresse des Servers

EthernetServer server = EthernetServer(10001);   // der Port für die Kommunikation?

void setup()
{
  Ethernet.begin(mac, ip_server);   // das Ethernet Shield vorbeteiten
  Serial.begin(9600);               // Ausgabe auf den Serial Monitor ermöglichen
  server.begin();                   // Server Starten
}

void loop()
{

}

und hier der Client.

//Client
#include <Ethernet.h>
#include <SPI.h>


byte mac[] = {0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xEC};

IPAddress ip_client(192, 168, 1, 200); // IP Adresse des Client
IPAddress ip_server(192, 168, 1, 201); // IP Adresse des Servers

EthernetClient client(10001);          // der Port für die Kommunikation?

void setup()
{

  Ethernet.begin(mac, ip_client);     // das Ethernet Shield vorbeteiten
  Serial.begin(9600);                 // Ausgabe auf den Serial Monitor ermöglichen
 

  Serial.println("connecting...");

  if (client.connect(ip_server, 10001)) {
    Serial.println("connected");
  } else {
    Serial.println("connection failed");
  }
}

void loop()
{

}

Nur wie schicke ich jetzt ein Sinnvolles Datenpaket von A nach B

Wenn ich mein eigenes Protokoll schicken konnte würde ich es aus drei Byte's (damit habe ich genug reserve) zusammenbauen.

Erstes Byte für den Typ -> 1= Abfrage, 2 = Befehl
Zweites Byte für die Pin-Nummer
Dtittes Byte für den Wert. Logischerweiße 0 oder 1

könnte sowas funktionieren?

Währe mega wenn ich da einen richtig guten Ansatz hätte

4

Es kommt darauf an, was Du an Übertragungssicherheit erreichen musst.

UDP - Verbindungslos, geringer Overhead, Fire and forget
TCP - Verbindungsorientiert, höherer Overhead, stellt Zustellung (wenn möglich) sicher, erkennt unzustellbarkeit. Der Server in Deinem Beitrag ist TCP.

Innerhalb dieser Grundprotokolle kannst Du dann Deine 3 Byte als Payload senden.
Du musst also erst mal eine grundsätzliche Protokollentscheidung treffen.

Gruß Tommy

5

Wenn ich das richtig verstandenhabe,

dann soll der
Mega --> UNO ... LEDs einschalten
UNO --> MEGA ... Tastendrücke und Schalteränderungen mitteilen

Wenn das so ist, dann musst du auf beiden Geräten sowohl einen Client (zum senden) wie auch einen Server (zum Empfang bereit sein) machen.

Ich rate dir dazu, alle mögliche Daten die hin und her geschickt werden sollen, mal auf ein Blatt Papier zu bringen.

dieses 3 Byte Protokoll, bin ich nicht so ein Fan von.
Tendiere da eher in die Richtung Tag=Value[;Tag=Value] wen man kein JSON nutzen will/kann.

6

noiasca:
dieses 3 Byte Protokoll, bin ich nicht so ein Fan von.
Tendiere da eher in die Richtung Tag=Value[;Tag=Value] wen man kein JSON nutzen will/kann.

Warum so einen Overhead generieren?

Wenn man das 3-Byte-Protokoll sauber definiert hat (am Besten gleich als Kommentar oben in den Sketchen) ist es genau so einfach lesbar, wie type=wert, zumal hier als Inhalt nur boolsche Werte übertragen werden sollen.
Der einzige andere Wert ist Byte 2, als Pinnummer.

Gruß Tommy

7

wenn mal Text zu einem LCD gesendet werden soll, ein Farbwert zu einer RGB LED, ein Poti ausgelesen werden soll, ein Analogwert > 8bit gesendet werden soll. ICH würde es variabel halten. Du kannst es anders machen.

8

@TO
bitte verwende CODE TAGS und nicht Tabellen TAGs für den Sketch.
Uwe

9

Ich bin bei sowas ein Fan von udp.

10

Ich eigentlich auch, solange man nicht die Sicherheit von TCP braucht.

Das kann man aber auch im eignen Protokoll mit einbauen, dass der Empfänger z.B. mit dem Status des gerade geschalteten Ausgangs antwortet.

Gruß Tommy

11

UTP würde mir eigentlich langen. Die sicherheitsrelevanten aufgaben werden durch Not-Aus Relais übernommen.

noiasca:
Wenn ich das richtig verstandenhabe,

dann soll der
Mega --> UNO ... LEDs einschalten
UNO --> MEGA ... Tastendrücke und Schalteränderungen mitteilen

Könnte man fast so sagen nur mit dem kleinen unterschied:

MEGA --> UNO ... ist Pin 4 HIG oder LOW;
UNO --> MEGA ... Pin ist LOW

Wenn der UNO dem MEGA eine Nachricht schickt, dann nur wenn er dazu aufgefordert wird und eben auch nur eine Antwort auf genau diese Frage.

noiasca:
wenn mal Text zu einem LCD gesendet werden soll, ein Farbwert zu einer RGB LED, ein Poti ausgelesen werden soll, ein Analogwert > 8bit gesendet werden soll. ICH würde es variabel halten. Du kannst es anders machen.

Dass wird in diesem Projekt definitiv nicht passieren. Bis in 4 Jahren sollen die jetzigen Systeme durch KUKA Roboter ersetz werden. Bis dahin gilt es die Zeit mit einer Preiswerten Lösung zu überbrücken. Die erste SPS von 1980 hat sich nämlich verabschiedet. xD

OK aber nun zurück zum Thema.
Also: UTP langt aus

12

Der ganze Aufwand wegen einem Pin? Oder kommt da noch mehr?

Gruß Tommy

13

Nein natürlich nicht nur wegen einem.

ins gesamt handelt es sich um 13 Inputs und 7 outputs.

-> somit brächte ich ein 25 Adriges Kable auf 16m Länge. ihr kennt ja die Situation dort nicht aber viel Spaß beim verlegen.

14

Ethernet Kabel liegt schon?

Dann schaue Dir mal UDP an. Ich habe hier ab #32 mal ein Beispiel mit ESP8266 gebaut, das Vorgehen ist aber das Gleiche. Die Lib für Ethernet heißt mittlerweile (glaube ich) EthernetUdp.h.

Gruß Tommy

Edit: Wenn sich an dem angefragten Arduino ein Eingang ändert, hat das Zeit, bis er mal wieder angefragt wird?

15

Ja Ethernet liegt

Tommy56:
Edit: Wenn sich an dem angefragten Arduino ein Eingang ändert, hat das Zeit, bis er mal wieder angefragt wird?

Bis Jetzt wird der Sketch recht flott abgearbeitet. Es währe natürlich sinnvoll zu sagen das UNO beim betätigen eines Tasters einen Merker HIGH oder LOW setz. Der MEGA muss dann den Merker abfragen.

Im Worstcase wird bsp. Automatik AUS gedrückt und der Loop wurde kurz zuvor gestartet. Wen der Durchlauf mal etwas länger dauert kann es sein das (bis es zur abfrage der Tasters kommt) dieser schon wieder losgelassen wurde.

Tommy56:
Dann schaue Dir mal UDP an. Ich habe hier ab #32 mal ein Beispiel mit ESP8266 gebaut, das Vorgehen ist aber das Gleiche. Die Lib für Ethernet heißt mittlerweile (glaube ich) EthernetUdp.h.

Dein Protokoll arbeitet ja Hexadezimal und leider binn ich hinter das System noch nicht ganz gestiegen. :frowning: Ich versuch aber einfach mal was daraus zu ziehen.

16

Hexadezimal, dezima, binär sind nur unterschiedliche Darstellungsformen eines Bytes für den Menschen. Intern sind das immer die gleichen 8 Bit.

Gruß Tommy

17

Du must die Oinzustände sofort per udp verschicken, sobald du am Eingang einen StateChange feststellst, nicht erst, wenn der andere pollt. Das ist ja das geniale da dran. Man hat Kommunikation in beiden Richtungen im push Verfahren. Und zusätzlich kann man alle Sekunde oder so auch regelmäßig alle Status übertragen, falls mal eine Änderung verloren ging. Oder sich die Änderungen quittieren lassen.

18

ElEspanol:
Du must die Oinzustände sofort per udp verschicken, sobald du am Eingang einen StateChange feststellst, nicht erst, wenn der andere pollt. Das ist ja das geniale da dran. Man hat Kommunikation in beiden Richtungen im push Verfahren. Und zusätzlich kann man alle Sekunde oder so auch regelmäßig alle Status übertragen, falls mal eine Änderung verloren ging. Oder sich die Änderungen quittieren lassen.

Aber wie soll das den funktionieren? Wenn der Mikrocontroller gerade mitten im Loop beschäftigt ist, kann er doch nicht gleichzeitig die Daten die geschickt wurden verarbeiten.

Natürlich währe es schön wenn ich vor jedem Neuem Loop ein PAE (Prozessabbild der Eingänge) wie bei einer Richtigen SPS hätte. Aber ich glaube das würde sich zu negativ auf die Durchlaufzeit auswirken.

19

i_am_konsti:
Aber wie soll das den funktionieren? Wenn der Mikrocontroller gerade mitten im Loop beschäftigt ist, kann er doch nicht gleichzeitig die Daten die geschickt wurden verarbeiten.

Doch kann er. Aber auch deswegen sollten ja die loops so schnell wie möglich durchlaufen sein. Und in jedem loop-Durchlaufen wird abgefragt, ob was per udp reinkam. Und wen dem so ist, das Empfangene parsen und du hast die aktuellen Zustände.

20

Also... hab mich am Wochenende mit nen Freund noch einmal über das Thema gemacht. Aber wir/ich komme einfach nicht weiter.

Tommy56:
Ethernet Kabel liegt schon?

Dann schaue Dir mal UDP an. Ich habe hier ab #32 mal ein Beispiel mit ESP8266 gebaut, das Vorgehen ist aber das Gleiche. Die Lib für Ethernet heißt mittlerweile (glaube ich) EthernetUdp.h.

Auch hiermit komme ich irgendwie leider nicht weiter. In dem Sketch ist mehr was mich verwirrt als dass ich mir daraus was ziehen kann. :sweat_smile: