Hilfe - Arduino will Modbus Temperatursensor nicht auslesen (RS485 Linksprite)

Hallo,

bin neu auf dem Gebiet und versuche einen Modbus Temperatursensor über RS485 mit einem Arduino UNO anzusprechen.

Das ist das Shield was ich für die RS485 Kommunikation nutze:

Leider schaffe ich es nicht den Temperatursensor anzusprechen und Daten auszulesen. Wenn ich den Sensor über einen RS485 zu USB Adapter mit meinem PC verbinde und ihn über das Programm ComTestPro (kann man mit Modbusgeräten kommunizieren) auslese funktioniert es, mit meinem Arduino jedoch nicht. Ich verwende die ModbusMaster Library.

#include <ModbusMaster.h>

// pin used for TX and RX
#define MAX485_DE      3
#define MAX485_RE_NEG  2

ModbusMaster node;

void setup() {
  // set pins to output
  pinMode(MAX485_RE_NEG, OUTPUT); 
  pinMode(MAX485_DE, OUTPUT);
  // baud rate
  Serial.begin(9600); 
  // slave ID 1
  node.begin(1, Serial);
}

void loop() {
  //set pins pre transmission to high
  digitalWrite(MAX485_RE_NEG, HIGH);
  digitalWrite(MAX485_DE, HIGH);
  
  uint8_t result;
  // read 1 HoldingRegister at address 1
  result = node.readHoldingRegisters(1, 1);
  delay(1000);
  
  // set pins post transmission to low
  digitalWrite(MAX485_RE_NEG, LOW);
  digitalWrite(MAX485_DE, LOW);

  if (result == node.ku8MBSuccess)
  {
    Serial.print("TEMPERATURE: ");
    // print 1 Register of ResponseBuffer to Serial Monitor
    Serial.println(node.getResponseBuffer(1) / 100.0f);
  }
  delay(1000);
  
}

Ich habe alles Erdenkliche probiert, sehe aber meinen Fehler nicht. Einstellungen sind genauso wie in ComTestPro - 9600 Baud, Device 1, Register 1, #Register 1, Function 3, welche bei Modbus ja readHoldingRegisters entspricht. Habs auch schon mit readInputRegisters probiert wie in dem ModbusMaster RS485 Example.

Egal ob mit oder ohne Shield auf den Arduino aufgesetzt, kriege ich im SerialMonitor das Gleiche zu sehen, irgendwelchen Unsinn. Da gibt er dann bereits bei result = node.readHoldingRegisters(1, 1); irgendwelche Hieroglyphen aus, was eh schon seltsam genug ist, weil ich da ja gar kein Serial.print mache. Das würde ich wirklich gerne verstehen.
Zu Serial.println(node.getResponseBuffer(1) / 100.0f); kommt er gar nicht erst, weil result scheinbar =! node.ku8MBSuccess ist, was wenn ich das richtig verstehe soviel heißt wie, dass readHoldingRegisters fehlgeschlagen ist. Und da liegt der Hund begraben - warum? Mit ComTestPro funktioniert es doch auch.

Mit Voltmeter Spannung am Sensor gecheckt, liegt an.
Weiß da jemand Rat zu? Ich bin für jede Hilfe dankbar.

Viele Gruesse
Winterwurst

Hallo,

der Fehler ist hier

  Serial.begin(9600);
  // slave ID 1
  node.begin(1, Serial);

Du verwendest Serial doppelt, sowohl für die Modbus Library als auch für die serielle Ausgabe. Daher kommen die merkwürdigen Zeichen im seriellen Monitor, da die Modbus Daten auch dahin geleitet werden. Die Pins 0 und 1 sind ja nicht nur mit dem Shield, sondern auch mit dem USB des Uno verbunden.

Das scheint bei dieser Lib allerdings so gedacht zu sein, in einem Beispiel wird das da auch so gemacht. Wahrscheinlich werden nur Daten auf die RS485 geleitet, wenn die Steuerleitungen auf den Pins 2 und 3 entsprechend stehen.

Man muss aber bei Serial.begin die Baudrate einstellen, die der Modbus haben will. Den seriellen Monitor muss man entsprechend umstellen. Sonst wird das nicht gehen.

Wenn man das Shield mit einem Uno verwenden will, ohne dass die Modbusdaten die serielle Ausgabe stören, muss man wohl SoftwareSerial verwenden. Ansonsten eher einen Leonardo, da sind die Pins 0 und 1 nicht mit dem USB verbunden.

Hi ArduFE,

danke fuer deine Antwort. Ich verwende die Pins 2 und 3 im Code und habe auch die Jumper auf dem Shield entsprechend gesteckt. Monitor ist auch auf 9600 baud eingestellt.

Du sagst die ModbusMaster Library kann mit dem Shield nicht, wenn ich nun SoftwareSerial statt ModbusMaster verwende, ist das dann aber wirklich immernoch eine Modbuskommunikation mit dem Sensor? In Modbus werden ja Funktionen wie die in meiner Loop genutzten “readHoldingRegisters” und “getResponseBuffer” verwendet. Bei SoftwareSerial finde ich diese Funktionen nicht, da gibt es nur read und write. Ich frage nur, weil ich den Sensor mit Modbus ansteuern möchte.

Viele Gruesse
Winterwurst

edit: habe gerade das Programm mit SoftwareSerial aufgesetzt und bin direkt auf das obengenannte Problem gestoßen. Ich kann mit der Library keine Register auslesen wie bei ModbusMaster.

Hallo,

ich glaube du hast da einiges noch nicht verstanden

winterwurst:
Ich verwende die Pins 2 und 3 im Code und habe auch die Jumper auf dem Shield entsprechend gesteckt.

Das sind doch die Pins mit denen die RS485 zwischen Sende- und Empfangsrichtung umschaltet. Nicht die über die gesendet wird. Da müsste man sowieso checken, ob die so zum Shield passen, bzw. dieses richtig einstellen.

Natürlich hat SoftwareSerial keine Funktionen wie “readHoldingRegisters”. Dafür ist ja die Modbus Master Library da. Sie erweitert eine serielle Schnittstelle entsprechend.

Und da verwendest du Serial, also die Pins 0 und 1:

node.begin(1, Serial);   // Da wird die Schnittstelle festgelegt !

Damit hängen dann das USB-Interface vom Uno, der Microcontroller und die RS485 zusammen. Das gibt diesen Unfug im seriellen Monitor. Ist elektrisch und softwaremäßig ziemlicher Käse, funktioniert aber wegen der Richtungsumschaltung an der RS485 “irgendwie”.

Mit der Softwareserial sähe das eher so aus (ungetestet aus Beispielen zusammenkopiert):

#include <SoftwareSerial.h>
#include <ModbusMaster.h>

// Pins für Transceiver und Receiver Enable
#define MAX485_DE      3
#define MAX485_RE_NEG  2

ModbusMaster node;

SoftwareSerial mySerial(10, 11); // RX, TX      Pins ggf. so ändern, dass sie zum Shield passen

void setup() {
  Serial.begin(9600);             // Für den seriellen Monitor

  mySerial.begin(9600);         // Für den Modbus

  node.begin(1, mySerial);     // Jetzt mit SoftwareSerial

Hi ArduFE,

danke vielmals für deine ausführliche Erklärung, mir ist nun Einiges klar. SoftwareSerial stellt extra Pins zur seriellen Kommunikation zur Verfügung, damit die UART nicht gestört wird, welche ja auch mit dem PC kommuniziert.

Pins 0 und 1 sind also für den PC, zwei Pins kann man für die Modbus Kommunikation wählen (mit SoftwareSerial), wobei diese mit den Jumperkombinationen am Shield übereinstimmen muessen. Das habe ich gerade mit einer if-Schleife mit mySerial.available() probiert, das funktioniert auch. Habe jetzt mal Pin 4 und 5 für mySerial und auf dem Shield gewählt, weil bis hoch zu 10 und 11 geht der Steckbrückenplatz am Shield nicht.

RE und DE sind mir bei diesem Board aber noch nicht ganz klar. Ich füge mal den Schaltplan bei:

Da steht jetzt am Chip U2, dass RE und DE zusammen am Header 3 haengen. Je nach dem wie ich das jetzt jumper kann ich entweder TX (TX_CTRL) oder TX/RX (D9_CTRL) wählen. Muesste ich meinen Transceiver und Receiver im Code dann nicht darueber “enablen”? Mit DE auf Pin 3 und RE auf Pin 2 funktioniert die Modbus Abfrage nämlich noch nicht. :drooling_face: Da scheiterts wieder bei result == node.ku8MBSuccess.

#include <SoftwareSerial.h>
#include <ModbusMaster.h>

// Pins for transceiver and receiver enable
#define MAX485_DE      3
#define MAX485_RE_NEG  2

ModbusMaster node; 

SoftwareSerial mySerial(4, 5); // Pins 4 and 5 for serial communication



void setup() {
  // set pins to output
  pinMode(MAX485_RE_NEG, OUTPUT); 
  pinMode(MAX485_DE, OUTPUT);
  Serial.begin(9600); 
  mySerial.begin(9600); 
  node.begin(1, mySerial); 

  
}

void loop() {
   
    //set pins pre transmission to high
    digitalWrite(MAX485_RE_NEG, HIGH);
    digitalWrite(MAX485_DE, HIGH);
    
    uint8_t result;
    // modbus function 0x03    
    result = node.readHoldingRegisters(1, 1); 
    delay(1000);
  
    // set pins post transmission to low
    digitalWrite(MAX485_RE_NEG, LOW);
    digitalWrite(MAX485_DE, LOW); 
  
    if (mySerial.available() && (result == node.ku8MBSuccess))
    {
      Serial.print("TEMPERATURE: ");
      delay(1000);
      //Serial.println(node.getResponseBuffer(1)/100.0f);
    }

  delay(1000);
  
}

Hallo,

ich glaube da passt das Shield auch nicht ganz zur Library. Es ist eigentlich üblich, dass wie auf dem Shield diese beiden Steuersignale zusammengelegt werden.

DE steht wahrscheinlich für "Data Enable". Ist dieses Signal High, so gehen die Daten vom TX auf die RS485 Leitung. RE_NEG ist "Receiver Enable", das NEG bedeutet, dass dieses Signal bei Low aktiv ist, dann kommen die Daten von der RS485 auf RX.

Durch diese Negation braucht man nur einen Ausgang zum Steuern, ist er High wird gesendet, ist er Low wird empfangen. Manche Arduino Varianten wie die Teensy Boards können das sogar automatisch, bei jedem Serial.print wird automatisch der Steuerpin umgeschaltet.

Nur will diese Library anscheinend, dass die Signale getrennt geschaltet werden, weil sie Serial auch noch für was anderes nehmen will. Dadurch gelangen die Daten nicht auf die RS485, wenn der Arduino programmiert wird, oder der serielle Monitor verwendet wird.

Eventuell gibt es dadurch Probleme. Vielleicht muss man da noch was am Code der Library anpassen. Ich kenne die Library aber selber nicht, dazu kann ich nicht viel sagen.

Was haltet Ihr von #define MAX485_DE 9 und P2 2-3 gebrückt (D9_CTRL)?

Ja, klingt plausibel. Würde ich mal probieren.

Ich würde auch die Library ändern. Ich habe Arduino MEGA mit ner S7-1200 unterhalten lassen und ein KINCO HMI mit nem Arudino Nano beides ohne Problem.
Schaue mal hier in die Examples da ist auch was interressantes dabei
>HIER<
Gruß
DerDani

Hi Leute,

vielen Dank für eure Antworten.

@ArduFE & agmue:

Habe D9_CTRL mal ausprobiert. D2 und D3 auf dem Shield gebrückt, P2 2-3 gebrückt (D9_CTRL) mit folgendem Code und als das nicht funktionierte genau das selbe mit gleichem Code mit P2 1-2 (TX_CTRL) laufen lassen - selbes Resultat:

#include <SoftwareSerial.h>
#include <ModbusMaster.h>

ModbusMaster node; 

#define MAX485_DE 9

SoftwareSerial mySerial(2, 3);

void setup() {

  Serial.begin(9600); 
  mySerial.begin(9600); 
  node.begin(1, mySerial); 

  
}

void loop() {

    uint8_t result;
    digitalWrite(MAX485_DE, HIGH);
    result = node.readHoldingRegisters(1, 1); 
    delay(1000);
    digitalWrite(MAX485_DE, LOW);
  
    if (mySerial.available())
    {
      Serial.print("test_mySerial");
    }
    if (result == node.ku8MBSuccess)
    {
      Serial.print("test_node");
    }
    
  delay(1000);
  
}

Ich betrachte hier nun die Fälle mySerial.available() und result == node.ku8MBSuccess seperat um ihr Verhalten zu untersuchen.

if (mySerial.available()) ist nur dann erfüllt, wenn ich D2 und D3 selber vorher High und danach Low schalte. Nur dann springt die Spannung an den TX und RX Ausgängen des Shields auch zwischen 3 V (HIGH) und 0.65 V (LOW) (gemessen mim Multimeter). Sowohl mit TX_CTRL als auch mit D9_CTRL sind weder if (mySerial.available()) noch eine Spannungsänderung an den Ausgängen erfüllt.

An dieser Stelle muss ich mich fragen, was TX_CTRL und D9_CTRL dann überhaupt für einen Sinn haben. Wenn einer der beiden für RE und DE zuständig wäre, warum gibt es dann keine Spannungsänderung?

if (result == node.ku8MBSuccess) ist in keinem der Fälle erfüllt…

Das ist mein derzeitiger Stand. :drooling_face: Übersehe ich irgendetwas?

@volvodani

Ich habe es mal mit der von dir vorgeschlagenen <ModbusRtu.h> Lib probiert. Hier kriege ich alle 2 Sekunden eine 0 ausgegeben bei Serial.println(au16data[0]);. Auch hier habe ich es mit TX_CTRL und D9_CTRL versucht, in beiden Fällen kommen 0er raus. Hier deute ich das ebenso, dass ich den Sensor nicht ansprechen kann.

#include <ModbusRtu.h>
#include <SoftwareSerial.h>

// data array for modbus network sharing
uint16_t au16data[16];
uint8_t u8state;

/**
 *  Modbus object declaration
 *  u8id : node id = 0 for master, = 1..247 for slave
 *  u8serno : serial port (use 0 for Serial)
 *  u8txenpin : 0 for RS-232 and USB-FTDI 
 *               or any pin number > 1 for RS-485
 */
Modbus master(0); // this is master and RS-232 or USB-FTDI

/**
 * This is an structe which contains a query to an slave device
 */
modbus_t telegram;

unsigned long u32wait; 

SoftwareSerial mySerial(2, 3); // Pins 4 and 5 for serial communication


void setup() {
  Serial.begin(9600);//use the hardware serial if you want to connect to your computer via usb cable, etc.
  master.begin( &mySerial, 9600 ); // begin the ModBus object. The first parameter is the address of your SoftwareSerial address. Do not forget the "&". 9600 means baud-rate at 9600
  master.setTimeOut( 2000 ); // if there is no answer in 2000 ms, roll over
  u32wait = millis() + 1000;
  u8state = 0; 
}

void loop() {

  

  switch( u8state ) {
  case 0: 
    if (millis() > u32wait) u8state++; // wait state
    break;
  case 1: 
    telegram.u8id = 1; // slave address
    telegram.u8fct = 3; // function code (this one is registers read)
    telegram.u16RegAdd = 1; // start address in slave
    telegram.u16CoilsNo = 1; // number of elements (coils or registers) to read
    telegram.au16reg = au16data; // pointer to a memory array in the Arduino

    master.query( telegram ); // send query (only once)
    u8state++;
    break;

      case 2:
    master.poll(); // check incoming messages
    if (master.getState() == COM_IDLE) {
      u8state = 0;
      u32wait = millis() + 2000; 
        Serial.println(au16data[0]);//Or do something else!
    }
    break;
  }
}

Viele Gruesse
Winterwurst

Also ich tue mich da jetzt etwas schwer weitere Tipps zu geben, wenn ich die Hardware noch nie gesehen habe.

Ich würde aber mal sagen, an deinem Code ist das Handling der Steuersignale falsch. Wie schon oben beschrieben, muss man ja bei diesem Shield zwischen Senden und Empfangen umschalten.

Wenn man da readHoldingRegisters macht, wird da ja wahrscheinlich was gesendet und gleich darauf empfangen. Da macht ein delay meiner Meinung nach gar keinen Sinn.

Serial.println(au16data[0]);

Damit wird nur das erste Byte oder Zeichen ausgegeben, ist das gewollt?

Ich sehe den Parameter uint8_t u8txenpin, könnte der für D9_CTRL interessant sein?

Hi Leute, ich danke euch fuer eure Antworten.

habe mal ein Bild (1) der Hardware in den Anhang gesetzt.
P3 ist mit D3 gebrückt = TX
P4 ist mit D2 gebrückt = RX
Wenn ich im Programm die beiden Pins auf High setze, leuchten die LEDs D1 (gruen) und D2 (rot) rechts am Board. Außerdem misst man an den Ausgängen A und B des H1 eine Spannungsdifferenz von ~3 V, gehen die Pins wieder auf Low gehen die LEDS aus und die Differenz ist 0.65 V. Diese Spannungsdifferenzen messe ich auch am Sensor, die Verbindung steht also. Wenn ich nicht die Pins sondern D9 auf high/low setze, dann gehen die LEDs nicht an und die Spannungsdifferenze am Ausgang bleibt auf 0.65 V bestehen. Sowohl mit D9_CTRL als auch mit TX_CTRL. Oben links im Bild der Sensor (der schwarze Chip am unteren Ende). Viel Einstellmöglichkeiten gibts also nicht, eigentlich nur D9_CTRL und TX_CTRL.

Zu Serial.println(au16data[0]);
ich habe mal die ersten 50 Wörter ausgegeben (Bild 2)

for(int i = 0 ; i < 50 ; i++)
        Serial.print(au16data[i]);
        Serial.println();

Man sieht die ersten 16 Wörter sind 0, was ja auch der Größe des Arrays entspricht.

Zu uint8_t u8txenpin: Mir kommt das auch sehr suspekt vor, dass ich nirgendwo RE/DE toggle. Die Definition:

Modbus master(0);

kommt aus dem Beispiel der Library die SoftwareSerial miteinbezieht. Es gibt auch eine ohne SoftwareSerial, da sieht das ganze so aus:

/**
 *  Modbus object declaration
 *  u8id : node id = 0 for master, = 1..247 for slave
 *  u8serno : serial port (use 0 for Serial)
 *  u8txenpin : 0 for RS-232 and USB-FTDI 
 *               or any pin number > 1 for RS-485
 */
Modbus master(0,0,0); // this is master and RS-232 or USB-FTDI

Das passt besser zu dem was in dem Kommentar beschrieben wird, aber wenn ich dem Modbus Objekt 3 Parameter zu übergeben versuche, so wie das hier der Fall ist, dann wird nichts mehr ausgegeben, nichtmal mehr die Nullen. Das Programm arbeitet dann nur noch bis kurz vor master.query( telegram ); bevor es abbricht und void loop(); neu durchläuft…
Ich habe da alle Möglichkeiten durchgeprüft, z.B. Modbus master(0, 9, 2) mit Jumper sowohl auf D9_CTRL als auch TX_CTRL.

Ich muss sagen das erscheint mir alles sehr seltsam. Wenn ich den Sensor direkt über Adapter an den PC anschließe und mit ComTestPro anspreche bekomme ich auch etwas Gescheites zurück. ComTestPro macht ja auch nichts anderes als die eingestellten Parameter mit einem Modbus Telegram an den Sensor zu schicken. Die Arduino Libraries machen ja das Gleiche. Das heißt das Problem hängt definitiv mit dem Shield zusammen, oder was meint ihr?

Bild 3 zeigt die Parameter die ich in ComTestPro übergebe.

Viele Gruesse
Winterwurst

Bin gerade über dies gestolpert:

uint8_t u8id; //!< 0=master, 1..247=slave number
uint8_t u8serno; //!< serial port: 0-Serial, 1..3-Serial1..Serial3; 4: use software serial
uint8_t u8txenpin; //!< flow control pin: 0=USB or RS-232 mode, >0=RS-485 mode

Modbus master(0, 4, 9) zusammen mit D9_CTRL oder
Modbus master(0, 4, 2) oder
Modbus master(0, 4, 3) jeweils zusammen mit TX_CTRL, weil D3 Tx sein sollte.

Hi agmue,

vielen Dank fuer deine Antwort.

Habe alle drei Vorschläge ausprobiert, aber es gab keine Ausgabe auf dem Monitor. Dann habe ich versucht mithilfe des Monitors zu debuggen. Dazu an fünf verschiedenen Stellen des Codes jeweils die Zahlen 1 bis 5 ausgegeben:

#include <ModbusRtu.h>
#include <SoftwareSerial.h>

// data array for modbus network sharing
uint16_t au16data[16];
uint8_t u8state;

/**se
 *  Modbus object declaration
 *  u8id : node id = 0 for master, = 1..247 for slave
 *  u8serno : serial port (use 0 for Serial)
 *  u8txenpin : 0 for RS-232 and USB-FTDI 
 *               or any pin number > 1 for RS-485
 */
Modbus master(0, 4, 3); // this is master and RS-232 or USB-FTDI via software serial

/**
 * This is an structe which contains a query to an slave device
 */
modbus_t telegram;

unsigned long u32wait;

SoftwareSerial mySerial(2, 3);//Create a SoftwareSerial object so that we can use software serial. Search "software serial" on Arduino.cc to find out more details.

void setup() {
  Serial.begin(9600);//use the hardware serial if you want to connect to your computer via usb cable, etc.
  master.begin( &mySerial, 9600 ); // begin the ModBus object. The first parameter is the address of your SoftwareSerial address. Do not forget the "&". 9600 means baud-rate at 9600
  
  master.setTimeOut( 2000 ); // if there is no answer in 2000 ms, roll over
  u32wait = millis() + 1000;
  u8state = 0; 
  Serial.println("1");
  delay(2000);
}

void loop() {
  switch( u8state ) {
  case 0: 
    if (millis() > u32wait) u8state++; // wait state
    Serial.println("2");
    delay(2000);
    break;
  case 1: 
    
    telegram.u8id = 1; // slave address
    telegram.u8fct = 4; // function code (this one is registers read)
    telegram.u16RegAdd = 1; // start address in slave
    telegram.u16CoilsNo = 1; // number of elements (coils or registers) to read
    telegram.au16reg = au16data; // pointer to a memory array in the Arduino
    Serial.println("3");
    
    master.query( telegram ); // send query (only once)
    Serial.println("4");
    u8state++;
    break;
  case 2:
    master.poll(); // check incoming messages
      Serial.println("5");
    if (master.getState() == COM_IDLE) {
      u8state = 0;
      u32wait = millis() + 2000; 
      for(int i = 0 ; i < 10 ; i++ )
        Serial.print(au16data[i]);//Or do something else!
    }
    break;
  }
}

Bild 1 im Anhang zeigt was auf dem Monitor zu sehen ist.

Bei master.query resettet er einfach das gesamte Programm? Wie kann das sein, dass er nach 3 einfach wieder 1 ausgibt, dazu muss er ja wieder ins Setup. Verstehst du das?

edit: Ich habe mal den von dir verlinkten Header ModbusRTU.h in Notepad++ geöffnet, um zu schauen wo der Fehler sein könnte und habe dazu die selbe Methode wie oben angewendet. Bei Modbus::query nach und nach die LED D2 von meinem Shield getoggled und einen kleinen delay dahinter, damit ich sehe wenn es passiert. Header eingebunden und Modbus::query durchläuft er zunächst tadellos. Am Ende von dieser Funktion springt er jedoch in sendTxBuffer(). Da habe ich die Fehlersuche fortgeführt und die Problemstelle entdeckt, an dem das Programm wieder auf Null zurückspringt:

if(u8serno<4)
        port->write( au8Buffer, u8BufferSize );

Wohlgemerkt bei u8serno<4, nicht bei dem darauf folgenden:

else
        softPort->write( au8Buffer, u8BufferSize );

Habe also mal überprüft und obwohl ich bei Modbus master(0, 4, 3) eine 4 für u8serno übergebe, ist bereits gleich danach bei Modbus::begin() wieder u8serno == 0… Und dann versucht er dieses au8Buffer welcher das CRC enthält auf den Port “port” zu schreiben, statt auf softPort, welcher ja &mySerial enthält.

edit2: u8serno im Header manuell zu 4 zu setzen, macht zwar, dass es zu softPort->write( au8Buffer, u8BufferSize ); kommt, aber da resettet das Programm ebenfalls…

Das ist mein derzeitiger Stand… Sorry für die ausschweifenden Antworten. :sweat_smile:

Viele Gruesse
Winterwurst

Bild 1.PNG

winterwurst:
... da resettet das Programm ...

Mir sind nur diese Möglichkeiten, die zu einem Reset führen, bekannt:

  • Reset-Knopf drücken (machst Du nicht)
  • Reset-Eingang auf LOW
  • Programmsprung zur Adresse 0 (wohl nicht)
  • Speicherüberläufe
  • Spannungsausfall, kann man eventuell an der flackernden Power-LED sehen, durch Überlastung oder Kurzschluß.

Such Dir was aus :slight_smile:

Hallo agmue,
danke fuer deine Antwort.

Das Einzige das da in Frage käme, denke ich, wäre Speicherüberläufe. Weiß aber leider auch nicht wie ich das nachprüfen koennte...

Naja, am Ende des Tages läuft es darauf, dass der Sensor einfach nicht antwortet. Habe die Fehlerstelle nun auch bei der ModbusMaster Library gefunden:

if ((millis() - u32StartTime) > ku16MBResponseTimeout)
    {
      u8MBStatus = ku8MBResponseTimedOut;
    }

In die Schleife springt er rein. TimeOut also. Bei ModbusMaster gibts keinen Reset.

Mal ne allgemeinere Frage:

Wenn der Flow Control Pin entweder auf RE oder auf DE steht, müssten sich dann nicht die Spannungen an den RX und TX Pins ändern? Weil das tun sie bei meinem Shield nicht...

Der Schaltplan ist ja nicht so kompliziert, da könntest Du ein Signal verfolgen. Du sendest ständig etwas über SoftwareSerial. Der Tx-Pin am Arduino müßte das Signal zeigen, ebenso am Jumper P3 und die TX-LED müßte flackern, ebenso am Pin 4 vom 75LBC184. Ist DE HIGH, sollte auch an A und B was zu messen sein.