electrodesigns.net

Here is a very simple example of testing Modbus-TCP with Mango M2M. TCP is a convenient way to transport sensor/control data. The lower layers of TCP insure data reliability. This example only simulates a quick integration of a Modbus-TCP enabled remote terminal unit (RTU) with a SCADA (Mango in this case); it doesn’t give any details of Modbus RTU itself. Modbus data may transported through many other physical media as well, RS485 being the most common. There are several reasons I personally recommend Ethernet over RS485, this post may give you an idea why. This is true not just for Modbus but any communication protocol.

• The first step is to download Modbus Slave utility from here. The is only a 10 minute demo but will serve our purpose. You can search a better option for yourself. Open up the program and click “Connection”, choose “Modbus TCP/IP”.

Alarm monitoring is a popular field where multiple network node, some times called agents, get information from attached sensors and transmit it onto the network where one or multiple servers called network monitoring system(s) (NMS) are listening to these alarms. The NMSs gather the info, calculate the statistics and present them in a way which is easily readable for human operators. The operators, then, are able to take quick decision based on these statistics.

This practice is very common in large networks where every single server, router or any other device typically keeps its own MIB (management information base) file and maintains it according to device condition. The device, other than doing it specific job, also send alarms which are typically called traps to the NMSs. However, the field has extended to general purpose small embedded devices as well for multiple applications like, power monitoring, environment and security to name a few.

(continue reading…)

In recent time I came across situations where RS485 ports caused lots of problems. The ports basically “burnt down” due to severe EM surges in industrial environment. As a work-around we used to bring in the systems from the site to our repair workshop, repair the device and then re-installed it on the client site. The equipment was expensive and we could not keep many drop-in replacements for that. Then what we did was to add a small hardware which basically translated the RS485 data into TCP/IP over Ethernet. The results were exceptional. This not only completely eliminated the damages due to surges but also reduced the customer annoyance, the logistic and support expanses we faced every time we received a May-day call. So, why should we replace or phase out the RS485 systems with Ethernet:

• Better isolation and hence no burning cases, this reduces cost
• Ethernet is faster
• Ethernet may provide different logical channels on the same physical medium like in one device, I used two TCP ports on same IP. One port for RS485 communication while the other one for digital triggers. This completely eliminated the “muddling” issue of two different data sources while using single physical Ethernet port.
• Much better stack structure in Ethernet as you have lots of options like TCP client, server, HTTP server, SNMP etc. according to requirement.
• Easier and smoother integration with existing TCP/IP-based network like local LAN.

Currently there are low-cost microcontrollers with built-in Ethernet controllers options like those offered by Microchip, TI and many others. This has eroded the myth of cost effectiveness of RS485 over Ethernet. Infact, keeping in view the running cost of both systems, Ethernet is much cheaper than RS485. Therefore, while designing a new system, Ethernet should be preferred over RS485 and if RS485 is already installed, low-cost converters can be used to transport data over Ethernet.

Often we come up to the situations where our newly design prototype is not working or malfunctioning. This situation becomes more interesting when hardware and software guys are working together on their respective parts of a  design.

Often our embedded boards are resource-limited and they doing something unexpected. Recently one of my software colleague was sending printing information to a handheld printer. My job was to translate the information on TCP to serial port through a small hardware designed by me. Everything was working on my side but when his data arrived, the printer could not print it properly. When I used to send the data through a little TCP client application running on my PC, the printer worked fine. Suddenly a thought flashed in my mind.  I had experienced such situation earlier when I was receiving a response from a remote TCP server which my TCP client could not understand properly. This time the situation was different but the problem seemed to me the same limited buffer space in my microcontroller’s tiny RAM. I told the software guy to send data with little time delays. The printer worked correctly this time. The reason was TCP port is a fast port and the serial port is a slow port, much slower than Ethernet. My embedded device’s buffer overflown before it could serve the previous packet. This has not been for the first time with me. In the early days of my professional life, I used to complain more. But experience has taught me to always remember “check yourself first”. So in the world of embedded systems, always be ready for something unexpected. And the fault usually lies within our designs.

Before complaining to the software guy, make sure that everything is working fine at your end. There are hardware, software debugging and sniffing tools available which greatly help to investigate the problem. For example if you are communicating on TCP, use Wireshark or similar tools to sniff the data and see if it follows desired packet structure. Similar are tools like TCP Toolkit for TCP, COMPort Toolkit for serial port and many other useful tools. Take advantage of free online tools to verify your design and only after then call your colleague to look into the matter.

Case Study:

I was assigned to design an Ethernet and WiFi enabled device for hospitality industry. I was looking for TCP/IP client functionality in my hardware so that I could talk to a remote server to fetch a key to write into an RFID tag. At that time I was used to Microchip and MikroC tools. This was somewhere in 2008. At that time only baseline of PIC32 was offered and no PIC32 with Ethernet was there. The only offering was En28J60 standalone chip and PIC18F97J60 families. I chose PIC18F97J60 because it had everything built-in. To my surprise, there was no TCP client library available in mikroC compiler (in mikroC world, everything including IDE, compiler and libraries used to come together in a single installation). When I looked at MIcrochip TCP/IP stack, plenty of libraries were available. At that point, I thought I should had put my “time and effort investment” in MCC18 rather than mikroC (BTW mikroC is a great start for newbies).

Advantages

• Getting started early.
• Sometimes you get same or better functionality in lesser price.

Disadvantages

• Always behind the features offered by official tools
• Usually incompatible with official tools debugger/programmers

Make sure that..

The hardware tools offered by third-party compatible with those of original vendor. Like the official IDE can debug the third-party development board  as well.

However, I think that if the official tools are free, then first party tools should be used. Like MPLAB for PIC, Keil for ARM etc.

The largest part of my career was to design network connected devices also called “internet of things”. Ethernet has a very effective way to collect alarms and pass to a remote server, translate other protocols like RS232/485 to TCP, alarm systems, home automation and other applications. I had the chance to “taste” different embedded microcontrollers and TCP/IP stack to encounter. Device in the list include PIC18, PIC32, Stellaris controllers while the stacks include Microchip’s propriety TCP/IP stack, lwIP, uIP.

uIP is the simplest and smallest stack with minimal footprint, however, the available stack APIs are limited.

lwIP is probably the most used embedded TCP/IP stack used by dozens of vendors. Because of open source nature and the “operating system emulation layer”, it is adopted by many MCU vendors including some 8051 variants and ARM “cousins” use the same stack with necessary relative adoption.

Microchip TCP/IP has the limitation that it can be used only on Microchip product. However, it is the most complete and greatly organized TCP/IP stack I have seen. It has every thing, every set of protocols a developer may need with the great thing inherited by Microchip is the great documentation; everything very well explained with examples. The stack has built-in support for Ethernet as well as WiFi. Microchip has its own WiFi modules available which can be integrated with PIC MCUs via SPI bus. The stack fully supports TCP, UDP, HTTP, SNMP, SNTP, and virtually every protocol which an average Embedded Systems Engineer needs.

In a practical implementation of Ethernet connected devices, I came across on implementation of lwIP over Stellaris. One thing which stung me was that you need to build the file system (fs) using “makefsfile” utility just like “MPFS2″ utility. But it will give you plan C files to be compiled with source to burn into the device. Unlike this MPFS2 give a separate .bin file which you can upload onto the device “on-the-go”. This seems to me a big advantage of Microchip tools over lwIP implementation for Stellaris.

Welcome to the internet of things!