That's all about Modbus, I hope.
By adding the Modbus-TCP library for the Windows Phone, you'll be able to control remotely with ease your Netduino (or any other 3rd party Modbus device).
http://highfieldtale...-windows-phone/
The Modbus server side could be used for the Go! as well, but it requires any TCP/IP interface to communicate.
Modbus-TCP is now for Windows Phone too
Started by Mario Vernari, Apr 22 2012 03:39 PM
8 replies to this topic
#1
Mario Vernari
-
- Members
-
- 1768 posts
Advanced Member
- LocationVenezia, Italia
Posted 22 April 2012 - 03:39 PM
Biggest fault of Netduino? It runs by electricity.
#2
hanzibal
-
- Members
-
- 1287 posts
Advanced Member
- LocationSweden
Posted 04 May 2012 - 06:43 PM
Nice, what can the modbus be used for?
#3
Mario Vernari
-
- Members
-
- 1768 posts
Advanced Member
- LocationVenezia, Italia
Posted 05 May 2012 - 04:47 AM
Nice, what can the modbus be used for?
The MODBUS is a protocol for data exchange, tailored for low-resources devices, because is very easy to implement.
A real showcase.
About 15 years ago we had a customer asking for an automation of a greenhouse. This greenhouse was plenty of sensors and relays, which had to be controlled by a central unit (i.e. the "brain"). Since the size of the greenhouse, the sensors were pretty far each other, thus there were several "satellite" I/O devices, collecting just the sensors' data.
You may think the system as one "brain" Netduino, plus several more Netduinoes (pretty far each other) for the sensors and relays.
How these devices could communicate each other?
Even nowadays the answer is not so simple.
You may be tempted to say "wireless", but it's rather expensive. Also a cabled Ethernet is expensive, and you can't run very long distances. Moreover, at that time there was no any easy solution for the TCP, nor the web was so diffused. In other words, the hardware for any TCP/IP based system is still pretty complex.
So, the only way was connecting them via serial: specifically UART, using the RS-485 interface. That's still a very good solution, because it's the only answer to several constraints:
- simplicity (both hardware and software);
- cost effective (can be realized even on a half-Euro MCU);
- reliability (very high noise immunity);
- very long distance wiring (up to 1.2km);
- worldwide standard, thus thousands of sensors can be plugged without no effort;
- no need of permissions, instead of most radio-based systems (*).
In other words, when a remote I/O device is asked for its status (input and analog ports), in which way it should "format" the collected values?
Again, when the central unit wants to turn on/off a relay, how should format the data on the serial?
Anyone of us might have a different way to serialize the data across the communication line. BTW, there are "infinite" ways to do that.
However, we would like:
- avoid reinventing the wheel;
- don't waste time designing "YACP" (yet-another-communication-protocol);
- follow some standard guideline, so that many 3rd party devices can connected easily (=speak the same "language")
The MODBUS is not reliable as the Profibus, which is used for hard-realtime control, such as plant-robotics and so. However, the MODBUS simplicity made is fortune because "even a chimp can implement it".
There are millions of systems communicating with MODBUS. There also thousands (maybe millions) of 3rd party smart-devices exposing their interface via MODBUS. The advent of the TCP/IP involved the MODBUS as well, but no manufacturer wanted to redesign their systems. So, the MODBUS-TCP (or -"over TCP") are variants of the basic protocol, which require very little modifications.
Conclusions.
If you want to exchanging data among PCs, there's no doubt that web-services or similar is the best way to achieve the goal.
Instead, if you have many Arduinoes, of sure you can't afford the weight of a web-service (nor any TCP-IP stack, or XML). In such a case, MODBUS is an effective answer to the problem.
In a Netduino context, well...even using the Plus, I'm not sure that the Ethernet way could be the best choice.
Specifically, consider the new Go!, which offers a well-tailored protocol for communicating with its modules: how to move a module pretty far from the base, using a tiny MCU as module core?
Hope it helps.
Cheers
- Nevyn likes this
Biggest fault of Netduino? It runs by electricity.
#4
hanzibal
-
- Members
-
- 1287 posts
Advanced Member
- LocationSweden
Posted 05 May 2012 - 09:07 PM
Great, thanks for that extensive answer Mario. As I understand from your explanation, Modbus is a actually a protocol and here you've implemented it over TCP/IP and added an interface to the Windows Phone as well. That's awesome!
#5
Kermit
-
- Members
-
- 78 posts
Advanced Member
- LocationCittà di Castello, Italy
Posted 08 May 2012 - 09:20 PM
So, the only way was connecting them via serial: specifically UART, using the RS-485 interface. That's still a very good solution, because it's the only answer to several constraints:
- simplicity (both hardware and software);
- cost effective (can be realized even on a half-Euro MCU);
- reliability (very high noise immunity);
- very long distance wiring (up to 1.2km);
- worldwide standard, thus thousands of sensors can be plugged without no effort;
- no need of permissions, instead of most radio-based systems (*).
Mario, here you said that we can realize an RS-485 connection with half-euro: could you elaborate on this, giving some advice, for us mere mortals? :-)
Thanks as usual from Città di Castello! :-)
Andrea
#6
Mario Vernari
-
- Members
-
- 1768 posts
Advanced Member
- LocationVenezia, Italia
Posted 09 May 2012 - 04:34 AM
Andrea, the very best thing is talk each other via Skype or so.
So, I've written about the implementation of the Modbus. It's very simple, thus you can fit the protocol even on a very cheap/tiny MCU. However, it needs for some extra hardware, and it can be easily above the "half-Euro"!
Back to your railroad problem (assuming is still alive).
Modbus is a good solution for your case. You have a large railroad plate, with dozens of I/O, and you wish to drive from a "central unit".
Now, it has no sense super-charging the central Netduino, so that will have dozens of I/O. First off, because you'd need tons of thick wire, then for the limited resources of the Netduino itself.
Instead, it could be interesting a "satellite" structure. Suppose having several MCUs, each one driving a limited number of I/Os. Also, each board would be placed close to the lights/raiload switch, so the wiring will be very short. At that point, each board would communicate with the central unit via a simple wire pair, and that could be RS-485 or similar.
For your specific case, I'd see better the CAN-bus, than the RS-485. That's not involving the protocol, but I guess it would be a little cheaper.
Well, about the "satellite" boards.
Each "slave" board could be a Netduino, of course, but it's an overkill. First off, because it would be expensive, and secondly because its task is much simpler than the central unit (a.k.a. the brain). Instead, each board could be realized over an AVR or ST microcontroller. The fastest way is surely choosing a certain flavor of Arduino, but the ST-way is also interesting.
Now, please have a look at the attached picture.
It's a fictional railroad plate ("stolen" from a Maerklin suggestion), which could look as your's. It's pretty huge, because it takes a whole room.
I've placed five labels "S1..S5" for the supposed point of the satellite boards. If you notice, these boards have been placed close to the switches, so the wiring will be very short. In other words, you should place a board and wire shortly to some switch and some light.
The "CU" label refers to the "Central Unit", which could be realized with a Netduino, and where the human "drives" the whole r/r model.
How to communicate with these boards?
Simply using a wire pair, or maybe a double-pair whereas the remote power supply will be preferable.
Along the communication pair, it can be used RS-485 or CAN (or else), using the Modbus protocol.
I'm pretty sure that you're saying: "damn, that's cool!...when may I begin?"
The problem is that there's several task to do. It's not easy as drinking water. I repeat: if you are not in a hurry, that could be realizable in some month. I'll happy to help you, but my spare time is limited...that's the reason for "some month"!
Contact me via e-mail (anytime) or via Skype (before dinner).
Cheers
Attached Files
-
railroad-plate.jpg 48.58KB
37 downloads
Biggest fault of Netduino? It runs by electricity.
#7
Kermit
-
- Members
-
- 78 posts
Advanced Member
- LocationCittà di Castello, Italy
Posted 09 May 2012 - 10:17 AM
Mario, you are always way too kind and gentle, with an in-expert like me.
As for Skype, I cannot use it for most of the day: moreover, I think that your expertize can be very useful to many people, so it would be wonderful if you could go on posting your thoughts here...
Yes, the railroad project is still alive, and I added an animated nativity for the church (and we hope to do it for Christmas!), so, since my spare time is very little, too, I think that I can get both projects done for the end of the year (no hurry, on my side! :-)).
You touch an important point on your last post: since I have a small consulting firm, specialized in Microsoft technologies (only software, at the moment), I would like to stress the functionalities of the Netduino to get the real grab on it. I've always been sure that only stretching the limits of things, I can deeply understanding potentialities of systems.
In this sense, for me it's not too important to have a perfect solution, for the problem under investigation: what I care most is to get some real case experience on Netduino projects.
That doesn't mean, of course, that in every situation I want absolutely use only a Netduino central unit, but that I want to do all I can to stay at least close to this (theoretical) solution.
There is another reason, too... I don't know any other MCU, apart from the name 'arduino', so I should start again studying another platform... I don't think I have this will... :-)
But, if you think it can be an interesting approach, could you point me to some inexpensive little board that I can link to the Netduino? Since I have a strong background in C/C++, I don't have any problem on these languages, but not worse! :-)))
Can we make them talk and sync together without relevant problems?
You are invaluable, Mario!
Andrea
#8
Mario Vernari
-
- Members
-
- 1768 posts
Advanced Member
- LocationVenezia, Italia
Posted 09 May 2012 - 11:52 AM
No problem for writing here. I was only suggesting to talk by voice, which is much faster!
The new Netduino Go! has been designed exactly for decentralized structures. It's a CPU (okay, a MCU, but its role looks much like a CPU), which "glues" several modules connected via Go!Bus. Most of the time, a module embeds a smaller/secondary MCU.
The problem is that is a system targeted for prototyping, and its bus can't reach long distances.
Andrea, your role is now more clear.
If you are going to prefer a "learning" solution, than a "engineered" one, you can also consider to create the system only Netduino based.
Now, without losing time, a quick question related to the "expected budget":
- supposing a railroad layout as the above imagined, also said "S" the number of satellite boards useful for the system management: is it okay for you purchasing S+1 Netduinoes?
Note that you will have to take in account some extra hardware, such wires, transistors, etc.
I'll wait for the answer.
Cheers
Biggest fault of Netduino? It runs by electricity.
#9
Kermit
-
- Members
-
- 78 posts
Advanced Member
- LocationCittà di Castello, Italy
Posted 09 May 2012 - 12:04 PM
I'm really sorry to change cards again... :-) I tried to do my homework, during lunch :-), so I googled to try to understand what you could mean, and I find out that I can buy a complete arduino solution for as little as 6 euros (ATMega328 + spare parts), so, if this is programmable in C/C++ and has characteristics similar, more or less, to the netduino, this can be interesting for other eventual ideas where cost is an essential factor.
So, now... ehm... if the satellites for the trains can be done using this solution, it would be even better; but now one IMPORTANT question comes to my mind: it's true that C#, visual studio, debugger, etc. etc., but what happens to my projects if ALSO the main unit becomes an arduino? Is it sort of a heretic question here??? :-)
I feel that I can ask this here, since I've been many times certified professional with microsoft, certified partner with my (small) consulting firm, and grown up with Microsoft C/C++ 6.0 in DOS: is there (still) anyone remembering this last one? I kept its manuals in my library even now! :-)))
Andrea
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
