||This is intended to be a stand alone, quick, easy method of performing some tests to an Ethernet based network.
| Start date:
| Last changed:
All YOU NEED TO KNOW ABOUT THIS PROJECT
In this project we want to test some network settings, without the use of a computer
- easy 3 button menu use
- Upload the sketch and start using it.
- Setup the Ethernet part on the device through the menu, use Dhcp or default
- Ping dhcp-server
- Ping gateway
- Ping DNS-server
- Ping any IP on the internet
- test if UDP packets from the cloud can reach the device
- Setup auto go back to the info menu
- Setup auto backlight off
- Setup the brightness of the backlight
- Setup the speed of cycling through the info menu
- Save all your changes to EEPROM
- Saving survives power failure and reboot
- Save, Discard, Cancel, Reboot
When answering a question on the official Arduino forum, I decided to make a project out of it. This is what John Powers told me about the project he needed.
As a Field Service Technician, I work alone, and routinely hava to install and commission equipment on a customers site in remote areas.
The best way I have to "look after" this equipment once I leave site is via remote (internet) access to the PLC (Programmable logic controller) and HMI (Human machine interface)To accomplish this, I use a variety of methods.
PLC, Connected to the customers LAN and accessible from outside (at home or in the office) by port forwarding.
Via a VPN connection through the customers LAN, or a Stand alone Broadband Internet (3G, 4G) modem/router (link to common NetComm model)
Connected directly to Broadband Internet modem/router with port forwarding enabled.
To compound this, the "PLC" I access also needs to be configured to work with the network provided. PLC's in a lot of ways are very clever and complex, but in many ways are in the dark ages. Configuring access via a LAN/Modem and the internet is still a "Hard coded" process, and is setup as part of the overall "program" loaded into the unit. This can make debugging a non-functional connection difficult.
Also, every PLC manufacturer (Siemens, Allen Bradley, Mitsubishi Modicon etc ) all have their own way of achieving the same result. Again, adding to the list of "things that can go wrong".
This idea came about while trying to get a reasonably large and complex multiple installation working on a greenfield site.
There were many variables (and many different errors in the install as it turns out) and being on my own with 1 laptop I was not getting very far.
What I needed was a way to "tick the boxes" and safely move on once I knew a certain part was working, and focus on what I didn't know.
In that install I had a combination of customer LAN and Modem/router connections. I also had a brand new (to me) type of PLC CPU that had a different configuration method from anything previously used.
I needed a device that I could walk between the installed systems, and check the connection at that point. What's wrong with the laptop I hear? Well, that is step 1, then I need to confirm I could indeed access that point from the outside. Because I couldn't be sure the PLC was configured correctly, I couldn't be sure where the link was falling down. So then I needed a device (web server) that could tell me if I was actually able to reach it from the internet. I needed my laptop at one end of the link, and something at the other.
Step 3 was I needed a Faux PLC, or something configured to behave like the PLC. In this case it required a fixed IP address and listening on a specific port only (Port 102 in this instance.) Once I confirmed that worked, I could then use my PLC specific software (for which the manufacturers charge BIG TIME) to attempt a connection to the Fake PLC. The proxy didn't need to fully behave like a PLC, but merely acknowledge that a connection attempt was in progress. Viola…I then new all the links in the chain worked and also my software was configured correctly. Any issues from here (and there were still some) MUST be in the PLC itself.
Sounds quite simple once it's sorted, but at the time, being able to prove each link (on my own) even to the point of proving the software config was ok, allowed me to focus my attention on the problem.
HARDWARE + SOFTWARE REQUIRED
- Arduino Ethernet
- 5V power supply
- LCD screen (compatible with Hitachi HD44780 driver)
- 3x push buttons
- 4x 1k Ohm resistors
- ICMPPing library
- TextFinder library: NO LONGER NEEDED STARTING WITH OzBeLAN V 0.8 AND UP
- adapted Ethernet library (to replace the one that comes with the Arduino IDE)
- Program to send UDP packets (Linux: sendip or nc / Windows: UDP Test Tool)
- ARDUINO IDE 1.0.3 YES YOU NEED AN OLD VERSION OF THE ARDUINO IDE
CIRCUIT OR SCHEMATIC
image developed using Fritzing. For more circuit examples, see the Fritzing project page
Schematic for the 3 button connection
| Schematic for the LCD screen (compatible with Hitachi HD44780 driver)
Schematic for the 3 button connection and the LCD screen
OzBeLAN V 0.1 first impression of the menu
OzBeLAN V 1.0 setting Ethernet to DHCP
OzBeLAN V 1.0 running ping tests and find my IP
OzBeLAN V 1.2 going through first configuration
ICMPPing library:https://github.com/BlakeFoster/Arduino-Ping The original library by Foster Blake. BETTER USE MINE !!!
UDP Test Tool:http://udp-test-tool.software.informer.com/
OzBeLAN_0_1: menu working 3 levels deep. with freetronics LCD shield. Buttons working. SAVE CONFIG and SAVE SETUP working
FROM DOWN HERE: you'll need something to send UDP packets for port testing UDP test tool
OzBeLAN_0_6: solved a lot of things and in this version all should work. You'll need something to send UDP packets for port testing.
FROM DOWN HERE: no need for the TextFinder library any more
OzBeLAN_0_8: stable version with smaller bugs and still without any shrinking.
OzBeLAN_1_0: Shrinked the whole sketch down to 27 950 bytes. No longer use of the TextFinder library
OzBeLAN_1_1: Found lot's of bugs in v 1.0 restarted from 0.8, solved the bugs, next version will be smaller: should be stable
OzBeLAN_1_2: Very small bux fix, but more important, this is a smaller version: 28078 bytes. Again, this one should be stable.
ICMPPing: uploaded the corrected files