Linking 2 Arduinos over ethernet

Using Arduino Programming Questions
1

Hi,
I have two Arduinos Uno with Wiznet W5100 Ethernet shield. I need to make them working this way that when digital input on first of them is made then the second one will get the digital output high. This will be of course used with more than one I/O but basically this is all I need from the program to do. The signals should be non-latching, i.e. the output stays high only as long as the input on second Arduino stays high.

Can you please point me to some sample code with relation to the above problem?

Regards
Michal.

2

A simple approach would be to use a web client on one uno to detect and send the data to the second uno running web server code to do the desired action.

3

Ostry:
...I need to make them working this way that when digital input on first of them is made then the second one will get the digital output high. ...

The Arduino Ethernet library supports UDP protocol, and, to me, a simple application can be handled quite, ummm, handily with very simple programs at each end.

I'll give example programs that use serial input on one board to send an 'H' or 'L' command to another board. The second board will turn an LED on or off, depending on what it sees in the incoming UDP packet.

For your purposes, instead of getting command(s) from serial input, you can use debounced switch state(s) to decide what commands to send (and when to send them).

First the "actuator" board that turns on an LED when it receives a UDP packet whose first byte is 'H' or 'h' and turns it off when it receives an 'L' or 'l':

/*
   UDPOutputBoard.pde
   
   The sender must know this board's IP address and port number.
   
   When this board receives a UDP packet whose first byte is
   'H' or 'h', it turns on the LED.
   When the first byte is 'L' or 'l', it turns off the LED.
  
   A confirmation UDP packet is sent back to the sender. 
   
   This code is in the Public Domain
   davekw7x

 */

#include <SPI.h>
#include <Ethernet.h>
#include <Udp.h>

// This board's MAC address on the Ethernet Shield
//  You can put just about anything here as long
//  as there are no other devices with an identical
//  MAC on the network.
//
byte mac[] = {0x90, 0xa2, 0xda, 0x00, 0x23, 0x16};

// For Arduino-to-Arduino connections you can use just
// about anything for this board's IP address as long as
// no other device on the network has the same address.
// If you are connecting to a LAN, use an IP address
// consistent with the network address and mask.
//
byte ip[]  = {10, 10, 5, 124};

const unsigned int localPort = 1369;

//
// Note that the buffer size for packet data, defined in Udp.h, is 24 bytes
// Since UDP packets, in general, can contain any data, you can't depend on
// a terminating zero byte. I'll make the buffer sizes one bye larger than
// the maximum "string" that I will send or receive.
//
char recvdBuffer[UDP_TX_PACKET_MAX_SIZE+1]; //buffer to hold incoming packet
char replyBuffer[UDP_TX_PACKET_MAX_SIZE+1]; //a string to send back


byte        remoteIp[4]; // Will save the originator's IP address from the received packet
unsigned int remotePort; // Will save the originator's port number from the received packet

// Since the SPI clock is on pin 13, I'll put the LED on another pin.
// Don't forget to put a resistor (in series) between Arduino pin
// and the LED.  I usually use 1K Ohms.
//
const int ledPin = 9;

void setup()
{
    // Set up the Ethernet Shield
    Ethernet.begin(mac,ip);

    // Open a socket for this port
    Udp.begin(localPort);

    Serial.begin(9600);
    pinMode(ledPin, OUTPUT);

}

void loop()
{
    // If there's data available, read a packet and echo it to the
    // serial port.  If it is a valid command, turn the LED on
    // or off.
    //
    int recvdSize = Udp.available(); // note that this includes the UDP header
    if(recvdSize) {
        
        Udp.readPacket(recvdBuffer,UDP_TX_PACKET_MAX_SIZE, remoteIp, remotePort);
        
        // We are expecting ASCII text, bu the packet data payload is not
        // necessarily zero-byte terminated.
        //
        recvdBuffer[recvdSize] = '\0';
        
        // Subtract the 8-byte header size so that we will read the data part.
        //
        recvdSize -= 8;
        
        Serial.print("Received packet data size = ");
        Serial.print(recvdSize);
        Serial.print(" from ");
        for (int i = 0; i < 4; i++) { // Print IP address xxx.xxx.xxx.xxx
            Serial.print(remoteIp[i], DEC);
            if (i < 3) {
                Serial.print(".");
            }
        }
        Serial.print(", port number ");
        Serial.println(remotePort);

        Serial.print("Contents: ");
        Serial.println(recvdBuffer);
        
        switch (recvdBuffer[0]) {
          case 'H':
            Serial.println("Turning LED on");
            digitalWrite(ledPin, HIGH);
            strncpy(replyBuffer, "H: LED is On",UDP_TX_PACKET_MAX_SIZE);
            break;
          case 'L':
            Serial.println("Turning LED off");
            strncpy(replyBuffer, "L: LED is Off", UDP_TX_PACKET_MAX_SIZE);
            digitalWrite(ledPin, LOW);
            break;
          default:
            Serial.println("No action");
            strncpy(replyBuffer, "Unknown command", UDP_TX_PACKET_MAX_SIZE);
            break;
        }
        Udp.sendPacket(replyBuffer, remoteIp, remotePort);
    }
}

Now, the "sensor" board that sends the command packets:

/*
  UDPInputBoard.pde

  Get an 'H' or 'L' from the serial port and send a UDP packet
  to another device on the network.  This board must know the
  output board's IP address and the port number that it is
  listening to.
  
  This code is in the Public Domain
  davekw7x

*/
#include <SPI.h>
#include <Ethernet.h>
#include <Udp.h>

// This board's MAC address on the Ethernet Shield
//  You can put just about anything here as long
//  as there are no other devices with an identical
//  MAC on the network,
//
byte mac[] = {0x90, 0xa2, 0xda, 0x00, 0x11, 0x07};

// For Arduino-to-Arduino connections you can use just
// about anything for this board's IP address as long as
// no other device on the network has the same address.
// If you are connecting to a LAN, use an IP address
// consistent with the network address and mask.
//
byte ip[]  = {10, 10, 5, 123};


const unsigned int localPort = 9631;
//
// Note that the buffer size for packet data, defined in Udp.h, is 24 bytes
// Since UDP packets, in general, can contain any data, you can't depend on
// a terminating zero byte. I'll make the buffer sizes one bye larger than
// the maximum "string" that I will send or receive.
//
char packetBuffer[UDP_TX_PACKET_MAX_SIZE+1]; //buffer to hold incoming packet,

// This is the IP address of the board that will be acting
// on our UDP packet command.
//
byte remoteIp[4] = {10, 10, 5, 124};

// This is the port number that the other board will be
// listening on.
//
unsigned int remotePort = 1369;

// I'll save received IP address and port number from acknowledgment
// packets in a different place, but  it's not really necessary,
// since this board's address and port are only used for startup
// purposes.
//
byte         recvdIp[4];
unsigned int recvdPort;

// Since the SPI clock is on pin 13, I'll put the LED on another pin.
// Don't forget to put a resistor (in series) between Arduino pin
// and the LED.  I usually use 1K Ohms.
const int ledPin = 9;

void setup()
{
    // Set up the Ethernet Shield
    Ethernet.begin(mac, ip);

    // Open a socket for this port 
    Udp.begin(localPort);

    Serial.begin(9600);
    pinMode(ledPin, OUTPUT);

}


// Really only needs to have length = 2, since will either send "H" or "L"
char UDPMessageBuffer[80]; 
void loop()
{
    // If there's data available, read a packet and echo to serial port.
    // If it is a valid LED command, send the UDP packet to the other end.
    //
    int packetSize = Udp.available();
    if(packetSize)
    {
        Udp.readPacket(packetBuffer,UDP_TX_PACKET_MAX_SIZE, recvdIp, recvdPort);
        
        // We are expecting ASCII text, but the packet data payload is not
        // necessarily zero-byte terminated.
        //
        packetBuffer[packetSize] = '\0';
        
        // Subtract the 8 byte header size so that we will read the data part.
        //
        packetSize -= 8;
        
        Serial.print("Received packet size = ");
        Serial.print(packetSize);
        Serial.print(" from ");
        for (int i = 0; i < 4; i++) { // Print IP address xxx.xxx.xxx.xxx
            Serial.print(remoteIp[i], DEC);
            if (i < 3) {
                Serial.print(".");
            }
        }
        Serial.print(", port number ");
        Serial.println(remotePort);

        Serial.print("Contents: ");
        Serial.println(packetBuffer);
    }


    // Now see if there is a user command.  Note that this part of the
    // code could do something else.  For example, it could get the
    // debounced state of a switch connected to an Arduino input pin
    // and send an 'H' or 'L' packet.  Stuff like that.
    //
    char inchar;
    if (Serial.available() > 0) {
        inchar = Serial.read();
        switch(inchar) {
        case 'H':
        case 'h':
            Serial.println("Sending 'H'");
            strcpy(UDPMessageBuffer, "H");
            Udp.sendPacket(UDPMessageBuffer, remoteIp, remotePort);
            break;

        case 'L':
        case 'l':
            Serial.println("Sending 'L'");
            strcpy(UDPMessageBuffer, "L");
            Udp.sendPacket(UDPMessageBuffer, remoteIp, remotePort);
            break;
        }
    }
}

Regards,

Dave

4

Outputs from sketches in the previous post. Tested with arduino-0022: Arduino Duemilanove boards with old Ethernet Shield and new Ethernet Shield connected directly. Note that the Wiznet chip does an automatic MDI/MDIX configuration so you don't need an Ethernet cross-over cable. Straight-thru works just fine, thank you very much.

The input board:

[color=blue]Sending 'H'
Received packet size = 12 from 10.10.5.124, port number 1369
Contents: H: LED is On
Sending 'L'
Received packet size = 13 from 10.10.5.124, port number 1369
Contents: L: LED is Off[/color]

The output board:

[color=blue]Received packet data size = 1 from 10.10.5.123, port number 9631
Contents: H
Turning LED on
Received packet data size = 1 from 10.10.5.123, port number 9631
Contents: L
Turning LED off[/color]

Embellishments might include timestamps, etc. Could write a history of events to an SD memory card (or other nonvolatile storage). Stuff like that.

Note that the actuator can receive UDP from any units on the network. You could have different actions based on senders' IP and/or port numbers. With longer packets you could include encryption. Etc., etc., etc.

With anything more elaborate than this simple example, you might want to develop one Arduino end at a time and use some kind of UDP sender/receiver program on your workstation (and a software Ethernet packet sniffer like Wireshark) to debug a little at a time.

Regards,

Dave

5

Hi Dave,
thank you for the code but I can't make this working after only uploading to the boards.

I noticed one thing in UDPInputBoard.pde:
Should line 74 be 'pinMode(ledPin, INPUT);' rather then 'pinMode(ledPin, OUTPUT);' as it is now ?

Also how to manage more than one pair of I/O?

Sorry for asking maybe such obvious questions but I am just starting my adventure with Arduino and trying not only use code produced by so much helpful people like yourself but also to understand it.

Regards

6

Ostry:
...I can't make this working after only uploading to the boards.

Thats worth of a big sigh from me. I'll tell you why in a minute

Ostry:
Should line 74 be 'pinMode(ledPin, INPUT);' rather then 'pinMode(ledPin, OUTPUT);' as it is now ?

Now, that's worthy of more than a sigh from me. It's a gasp. (Really: My flabber is totally gasted).

Ostry:
I am just starting

OK, now we have something I can work with. I mean, no one was born knowing this stuff, right? I am hopeful that you will accept the following criticism as my attempt to get you started, and not any kind of flame or other personal attack.

So, how's I got started with Arduino:

I looked at the very first test program example, the famous "Blink" sketch. In the current Arduino release there are, by my reckoning, a grand total of 19 lines. Two lines are blank, eight lines are comments and nine lines are code. (Two of the lines have a single '}' brace. That's part of the code.) I also looked at Arduino reference material on the arduino.cc web site. Now, I will admit to have done some amount of programming over the years, but this Arduino stuff was brand new, and I looked at a lot of reference material before ordering the board. (I also ordered a "starter kit" that had a solderless breadboard, a handful of LEDS and resistors, a light-dependent resistor and some jumper wires.)

Anyhow when the hardware arrived, I was ready to go!

I had made sure that I knew exactly what every line of code does in the example sketch. I looked up pinMode and digitalWrite. The comments were helpful. I plugged the Duemilanove into the a USB port on my computer. I started the Arduino IDE and used the menu to locate the "Blink" sketch. I compiled the sketch and uploaded to my Duemilanove. The LED marked "L" blinked at a rate of about one second on and one second off. It did this repeatedly until I unplugged the USB cable.

Next step: I wanted to make a different LED blink. I decided to try Pin 9 instead of Pin 13. Now, here's the tricky part: If you don't have a degree in Electrical Engineering or Computer Engineering, and if you don't read the right reference material you might not realize that the correct way is to put a resistor "in series" with the LED. What value of resistor? You can do some searches on this forum or on the Arduino "playground" or about a million other places on the web. (I looked at the Duemilanove schematic.) Bottom line, here's the way I connected the new LED:

Arduino pin 9 ---> 1 K Ohm resistor ---> Anode of LED

and

Cathode of LED ---> Arduino Ground.

After making the connections I plugged in the Duemilanove again. The "L" led (on Pin 13) did its blinky thing, because the old sketch stays in program memory after you unplug the power. When power is connected again, it the old program continues to execute until you upload a new sketch.

Next...

I opened the "Blink" sketch and everywhere there was "13" I changed it to "9"

Now, when I uploaded the modified sketch, my new LED (on Pin 9) blinked and the "L" LED (Pin 13) on the board stayed dark.

I went through the agonizing details for this simple step because I'm thinking you didn't do anything like that. If you had, you wouldn't have asked the flabbergasting question about the pinMode instruction. The LED is connected to a pin that is operating in Output mode so that it can cause current to flow through the LED (or not) to make the LED be illuminated (or not).

I hate to repeat myself, but I am not trying to disparage you or to discourage your efforts to learn something new that is really, really neat. (Well, this stuff is fun when it works, and I think that's neat.) I am trying to get you to think sequentially instead of starting with zero knowledge and jumping to a "do it from scratch" remote control pair of programs.

Don't get me wrong; it's always OK to ask questions (Really: I think it's always OK), but I personally think that anyone would be out of his/her mind to start a project with two (not one but two) Ethernet Shields connected and programmed in such a way that a switch at one board could cause an LED on the other board to go on and off.

I'm thinking that the Arduino developers didn't put in any kind of examples with two Ethernet Shields (on two different Arduino boards) because many (most?) beginners don't have two Arduinos, each with its own Ethernet Shield. Furthermore, people have enough problems getting just one of the furshuliggener things to work, let alone two.

I mean, that's a great project, in my opinion, and it's still amazing to me that a processor with such limited resources as an ATmega328 can perform useful network operations with a standard Ethernet protocol like UDP. Really. It's a great project, and I hope you can stick with it and learn enough to get satisfactory results. Really.

Now as far as my first sigh at the top of this response:

I try (really try) hard (really hard) not to publish sketches that don't work. That's not to say that I never make a mistake. It wouldn't be the first time I was wrong. (Not even the first time today.)

But look at the information I gave you: I told you what version of Arduino software that I was using. I told you what Arduino boards I am using. I told you what versions of Ethernet Shields I was using. I told them how I hooked them up. Well, actually I didn't tell you the circuit connected to pin 9 of the output board, but I assumed you already knew how to hook up an LED. (I'm not sure whether that assumption was a mistake, but I accept the possibility that I should have spelled it out.)

After all, you are getting into some rather advanced territory when you go around hooking up Ethernet cables to use with your very own hardware and software.

Anyhow...

I showed you exactly what I saw in the serial port monitor windows for both boards. I told you that the LED goes on and off on the output board when it receives the UDP packets.

What do I get from you? "It doesn't work."

OK: What doesn't work? Does the input board respond to input from the serial port? Does it print a message that it is transmitting the command? What? The same kind of questions go for the output board. Exactly what works )or doesn't work)? Do the Ethernet Transmit/Receive LEDs on the Ethernet Shield blink briefly when you want to send the 'H' or 'L' message? What?

Furthermore:
What are you working with? (What software version? What Arduino boards? what Ethernet Shields? What?)

Also:
Have you done any of the Ethernet example programs? The WebServer? The ChatServer? Anything?

What happens when you connect an Ethernet cable from one of your shields to your network? Do any of the lights go on? If you run one of the Ethernet library example sketches, do the Ethernet Transmit/Receive LEDs blink? What?

If you haven't done an example with one Ethernet shield connected to your network, I personally think you are simply not going to understand what happens when you connect two of them (on different Arduino boards) together. Maybe I am wrong. I mean, different people have different ways of learning, just as different people have different ways of trying to help.

Regards,

Dave

Footnote:
"The opinions expressed here are not necessarily my own,
but those of the dang voices in my head."
---davekw7x

7

"The opinions expressed here are not necessarily my own,
but of these dang voices in my head."
---davekw7x

I thought something was strange when I read your last post. Perhaps starting with a simple http client/server setup might be simpler and quicker.

8

zoomkat:
...Perhaps starting with a simple http client/server setup might be simpler and quicker.

Perhaps. But with the Arduino Ethernet library, http is transported with tcp, which requires the application program to establish a connection, and is, therefore not "simpler and quicker" than UDP at the phy or link layer (I think).

Perhaps you will submit two complete example sketches that use a command at one end to turn on (and off) an LED at the other end and show whether it is "simpler and quicker" at the application layer level. I am really interested.

Of course a "real" application like this would have the sensor board verify the returned acknowledgment and repeat the command if it didn't "take" (or if it timed out). That would also be required (in my opinion) if TCP were used. I know that TCP guarantees delivery of the message (with automatic repeats if no acknowledgment is received), but that doesn't guarantee the message was received correctly. It still needs some extra logic in the application. So...I'm trying to visualize at what level it is "simpler and quicker" to implement a web server and web client instead of UDP "Output Board" and a UDP "Input Board."

I mean it's not a contest (I don't do contests), but the actual networking part of the sketches I whipped out for this thread is something like a dozen lines of actual code each out of about 60 or so lines of actual code (if you leave out all those comments and empty lines---I like to see about 2:1 ratio of complete program to uncommented-unwhite-spaced bedrock code, and that's what those have).

Regards,

Dave

Footnote:
As for the voices: It's a curse. Sometimes I just can't help myself.

9

I mean it's not a contest (I don't do contests), but the actual networking part of the sketches I whipped out for this thread is something like a dozen lines of actual code each out of about 60 or so lines of actual code (if you leave out all those comments and empty lines---I like to see about 2:1 ratio of complete program to uncommented-unwhite-spaced bedrock code, and that's what those have).

My question is did you actually test your code communicating between two arduinos before you posted it or is it code that "should" work?

Below is client and server test code I use. The client sends a get type request (no query_string used in this example) to get a test file on a web server. I use the server code to operate two continous rotation servos. The code could be modified to do other things like blink an LED and such. I don't have two arduinos to test with, but I just tested both individually and they work for me. YMMV.

client code

//zoomkat 11-13-10
//simple ethernet client test code
//for use with IDE 0021 and W5100 ethernet shield
//modify the arduino lan ip address as needed
//open serial monitor to see what the arduino receives
//push the shield reset button to run client again

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

byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };
byte ip[] = { 192, 168, 1, 102 }; // Arduino IP address
byte server[] = { 208, 104, 2, 86 }; // zoomkat's web site

Client client(server, 80);

void setup()
{
  Ethernet.begin(mac, ip);
  Serial.begin(9600);
  Serial.println("starting simple arduino client test");
  Serial.println();

  delay(1000);

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

  if (client.connect()) {
    Serial.println("connected");
    client.println("GET /~shb/arduino.txt HTTP/1.0");
    client.println();
  } else {
    Serial.println("connection failed");
  }
}

void loop()
{
  if (client.available()) {
    char c = client.read();
    Serial.print(c);
  }

  if (!client.connected()) {
    Serial.println();
    Serial.println("disconnecting.");
    Serial.println("==================================");
    Serial.println("");
    client.stop();
    for(;;);
  }
}

server code

//zoomkat 10-22-10
//routerbot code
//for use with IDE 0021
//open serial monitor to see what the arduino receives
//use a url like below in a browser to test
// http://192.168.1.102:84/?-1450-1550 

#include <SPI.h>
#include <Ethernet.h>
#include <Servo.h>

byte mac[] = { 
  0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; //physical mac address
byte ip[] = { 
  192, 168, 1, 102 }; // ip in lan
byte gateway[] = { 
  192, 168, 1, 1 }; // internet access via router
byte subnet[] = { 
  255, 255, 255, 0 }; //subnet mask
Server server(84); //server port

String readString, servo1, servo2; 

Servo myservo1;  // create servo object to control a servo 
Servo myservo2;
//////////////////////

void setup(){

  //start Ethernet
  Ethernet.begin(mac, ip, gateway, subnet);
  server.begin();

  //enable serial data print 
  Serial.begin(9600); 
  myservo1.attach(7);
  myservo2.attach(6);
  Serial.println("bot21"); // so I can keep track of what is loaded
}

void loop(){
  // Create a client connection
  Client client = server.available();
  if (client) {
    while (client.connected()) {
      if (client.available()) {
        char c = client.read();

        //read char by char HTTP request
        if (readString.length() < 100) {

          //store characters to string 
          readString += c; 
        } 

        //if HTTP request has ended
        if (c == '\n') {

          ///////////////
          Serial.println(readString);

          //readString looks like "GET /?-1500-1500 HTTP/1.1"

          if (readString.length() >0) {
            Serial.println(readString);

            servo1 = readString.substring(7, 11);
            servo2 = readString.substring(12, 16);

            Serial.println(servo1);
            Serial.println(servo2);

            int n1;
            int n2;

            char carray1[6];
            servo1.toCharArray(carray1, sizeof(carray1));
            n1 = atoi(carray1); 

            char carray2[6];
            servo2.toCharArray(carray2, sizeof(carray2));
            n2 = atoi(carray2); 

            myservo1.writeMicroseconds(n1);
            myservo2.writeMicroseconds(n2);

            //myservo.write(n);
            readString="";
          } 
          ///////////////////

          //now output HTML data header
          client.println("HTTP/1.1 204 Zoomkat");
          client.println();
          client.println();
          delay(1);
          //stopping client
          client.stop();

          /////////////////////
          //clearing string for next read
          readString="";

        }
      }
    }
  }
}
10

zoomkat:
...
My question is did you actually test your code communicating between two arduinos before you posted it or is it code that "should" work?

I thought I was clear that the code was tested and works as intended with the setup that I listed: Issue a command at one end and the LED at the other end turns on or off. I threw in a lot of print stuff that, for me, makes verification (and debugging) easier.

I have been known to offer suggestions that try to point questioners in a direction that "should" work, but when I post complete sketches and state what the setup was and show output, the stuff is pasted directly from working systems. If it doesn't work for other people, then I would like to know their setup and I would like to know how, exactly, they tested it. It's always possible that there are errors in my code (or code from any other person on the face of the earth), and I know that it is, in general, not possible to prove a program is correct by testing alone. That's why I always appreciate meaningful feedback rather than a report that says nothing more than, "It's not working."

zoomkat:
Below is client and server test code I use.

I'm sure that code could be adapted so that the query from the output board (acting as a client) to the input board (acting as a server) could detect the state of input switches and act accordingly. That's not exactly the same as having the input board report immediately when a switch state changes, but it could give perfectly acceptable performance.

The Original Poster did not give any specific requirements as to timing, code size, network efficiency, etc.

I threw my little example sketches together to show one approach. Other approaches may be more suitable, depending on the experience level of the designer as well as specific requirements. I mean not everyone immediately thinks about HTTP and GET and all of that stuff to transfer sensor information to an actuator but for some people it's the first thing they think of. The fact that (most of) the TCP stuff involved with the HTTP approach is taken care of by the Wiznet chip without the Arduino program library having to add a lot of code to the sketch makes it feasible. I personally do not think it makes it "simpler and faster." But maybe that's just me. I'm funny that way.

Regards,

Dave

11

First of all thanks again for such big involvement in resolving my problem. When I first said 'It doesn't work' I realy didn't ment to make anyone upset.
I realy appreciate your input and it is absolutely not my intention to cause arguments/competitions/etc.
To make things a bit clarified I have background in electronics and also in computer networking therefore there's no need to worry if I got the LED connected the right way with resistor and if the network cable is ok (I should have mentioned this earlier). It is entirely my fault that I have not provided more details about my environment I run this. By saying that I am novice I ment this in relation to Arduino only.

I use Arduino UNO + ETHshield WIZnet 5100 on both ends + prototyping boards, cable without crossover. Software Arduino 0022.
I tested LED with 'blinking led' program and it works fine on every output I select.
I also did some experiments with http://arduino.cc/en/Tutorial/WebServer - worked fine and also with slightly modified http://arduino.cc/en/Tutorial/WebClient and I got the Arduino reading Google website and sending to serial port so all the hardware seem to be in good order.

I red all the code again and now understood the idea to trigger the output using L and H in the serial monitor.

I ran serial monitor and got the following when press l:
Sending 'L'
Received packet size = 13 from 10.10.5.124, port number 1369
Contents: L: LED is Off

Then I press h:
Sending 'H'
Received packet size = 12 from 10.10.5.124, port number 1369
Contents: H: LED is Onf

in both cases LED is actually going on/off so the program is working fine. I must have been blind or so when I was testing this last night.

The next question is how to make output triggered on the digital input and not on the command and make this working for multiple I/O's.
E.g. Input 3 high on input board=Output 3 high on output board together with any other pairs of I/Os.

12

Ostry:
...
The next question is how to make output triggered on the digital input and not on the command

OK, forget the network stuff for now, figure out how to make an output change when an input changes (on the same board).

In the Arduino Examples->Digital category:

Look at the Arduino "Button" example sketch, and then look at the "Debounce" and "State Change" examples. Try to figure out how to combine them and enhance to include reporting of more than one pin change.

When you thoroughly "get it," look at the Arduino "Button" library: http://www.arduino.cc/playground/Code/Button

Ostry:
make this working for multiple I/O's.

If you have more than one input, you can look at the inputs one at a time and do the action.

Then for the network action:
You can look at the inputs one at a time. If you see that an input pin has a value that is different from the last time you looked, then send a command to the other end (and wait for the acknowledgment).

You can think of sending commands in the form "H1" to set output 1 high and "L1" to set the corresponding output low. "H2" tells it to set output number 2 high. Etc.

Or...

Look at all inputs and combine their On/Off bit values into a single state variable (with a shift instruction followed by logical "or" for each bit or some such thing) If there are eight or fewer inputs, the state variable can be a byte (unsigned char). If there are from eight to 16 inputs, you can combine all of the in states into an an unsigned int (16 bits). Stuff like that.

Anyhow...If the new value of the state variable is different from the previous value, send the state variable (in a UDP packet or any other way that seems appropriate) to the other end. The sketch at the output board will unravel the received state value into individual bits for the corresponding outputs.

Or something like that...

Regards,

Dave

13

hi

i have proplem and i hope to help me quickly

when i verify the two code i face this error message

this is the messages

1 in code sender
int packetSize = Udp.available();

the error mesage is :
The Udp class has been renamed EthernetUdp

2 in code sender
int recvdSize = Udp.available();

the error mesage is :
The Udp class has been renamed EthernetUdp

sorry , but i learnning the arduino now and i have simple questions

14

abdullaziz:
hi

i have proplem and i hope to help me quickly

when i verify the two code i face this error message

this is the messages

1 in code sender
int packetSize = Udp.available();

the error mesage is :
The Udp class has been renamed EthernetUdp

2 in code sender
int recvdSize = Udp.available();

the error mesage is :
The Udp class has been renamed EthernetUdp

sorry , but i learnning the arduino now and i have simple questions

I have that problem too, maybe we don't have Udp.h library , anyone can help Udp.h for arduino library?

15

I have that problem too

What problem is that? A reading comprehension issue?

the error mesage is :
The Udp class has been renamed EthernetUdp

If that isn't enough of a clue by four, Arduino is not for you.