Today I published the version 2 (beta) of the Modbus libraries suite.
The most noticeable news is about the ordinary desktop .Net 4.5 support. This comes along a stunning Windows Store-like demo app for bidirectional testing with any Modbus-enabled Netduino.
This demo has been styled upon the brand-new Windows 8 “Modern-UI” rules, so that the incoming Windows RT libraries will feature a similar demo running on a tablet instead.
I also added the Windows Phone 8 support, but it looks exactly as the previous Windows Phone 7.5 release. I tested it only with the emulator not having any WP8-enabled phone.
First of all, I apologize for messing up the source in the Codeplex repository. I started using (Tortoise) Git, and I didn’t realize that only some files were been updated on the server.
Introduction.
So, well…this is the third (and the last?) part of the “Modbus saga” around Netduino, and the Micro Framework in general. I guess there’s enough stuffs to play with, at least for the moment.
This article is going to present the porting of the Modbus library for the Windows Phone platform. The MF library has been presented in my previous articles here and here.
The Windows Phone platform.
This is my very first application for Windows Phone. I’d say that I bought my new Nokia Lumia 800, just for experimentation other than for calling. I really can’t compare with any other phone, simply because I have no experience. By the way, it’s a very amazing machine, and if you look for genuine developing fun, that’s really satisfying.
Note that if I own a Windows Phone now, it’s because the great Paolo Patierno, giving me an excellent description of the framework/device. I was unsure, but he gave me several reasons for choosing a WP: thanks again Paolo for the good tip!
Porting the library written for the .Net MF to the Windows Phone (Mango) platform, was as easy as a walk in the park. By the way, I have a strong WPF knowledge because is my daily job, so the impact was almost insignificant. However, there are several considerations to keep in mind, because a phone is very different from a normal PC.
Probably you won’t believe me, but the most complex task was about the deployment. On a PC is trivial (especially using ClickOnce), but even on Netduino is very easy to upload an application to the board. For the Windows Phones is not so easy, instead.
To access your phone you must subscribe to the App Hub, which requires a fee yearly. Then, you have full access to upload any your app on your phone. I mean just for testing on your own device, not for distribute!. To take part of the Windows Marketplace, your app has to be certified. It’s a pretty complex task, and I still haven’t try, but I would try it.
The demo application.
The demo is very simple, yet straightforward to use.
It’s based on the raw I/Os exposed by the Netduino. It must considered the “Plus” version just because the Ethernet connection is required by the Modbus-TCP protocol.
The hardware bench can be set up in minutes. The first 8 I/Os (D0..D7) are supposed to be always inputs, while the remaining 6 I/Os of the row (D8..D13) are supposed to be always outputs. The analog inputs (A0..A5), of course, are meant as they actually are.
I have connected only 4 push-buttons for driving the inputs, and 4 leds for watching the output states. I also used a couple of trimpots for generating a variable voltage to feed two analogs. That’s enough for a small demo.
Note. The trimpots I’ve used are over 20 years old, and are clearly dirty, and full of dust. On the video below you can laugh by seeing the “effort” I’ve made to turn them.
Of course in the Netduino board I have uploaded the already known Modbus-TCP server library. So, the small board is waiting for incoming connection on the TCP port 502, as the Modbus specs suggest.
On the phone, the app firstly asks for the target host. It should asks for the Modbus address as well, but due the simplicity of the program I’ve skipped this kind of parameters. The address has been fixed to “1”, as in the Netduino is.
After the successful connection, a “panorama-page” presents the three-sections of the exposed I/Os: boolean inputs, boolean outputs (i.e. coils), and analog inputs. A clipped picture of the board helps to recognize easily the pins.
What else? The application explains by itself what to do: by pressing a button by the Netduino, the related “led” (simulated) is lighting up. Similarly, when you mark any of the outputs checkboxes, the related led will do also. For the analogs, there are three kinds of representation of the real-time value: the raw value (i.e. the ADC word read), the related voltage converted, and a percentage level bar.
The software.
Nothing much to say, other than I’ve used the new “async” features of the incoming .Net 4.5.
The application acts as a state machine, polling sequentially the input ports, then the output ports, then the analog ports, and start again. The phone framework does not allow any “synchronous” operation (I’d say also “fortunately”). That’s because the UI must be totally free from any hangs due to tight loops, or unexpected long processing. Instead, everything is async-based, and here the “async-await” pattern comes easy to help the development.
For example, the boolean inputs request can be written as follows:
private async void QueryDiscretes()
{
await TaskEx.Run(() =>
{
//compose the Modbus command to be submitted
var command = new ModbusCommand(ModbusCommand.FuncReadInputDiscretes);
command.Offset = 0;
command.Count = InputCount;
//execute the command synchronously
CommResponse result = App.Modbus
.ExecuteGeneric(App.Client, command);
if (result.Status == CommResponse.Ack)
{
//command successfully
Deployment.Current.Dispatcher.BeginInvoke(new Action(() =>
{
for (int i = 0; i < command.Count; i++)
{
var input = this._inputs[i];
input.Value = command.Data[input.Offset] == 0;
}
}));
}
else
{
//some error
}
this._status = MachineState.CoilRequest;
});
}
Note the “async” modifier immediately before the routine declaration, as well as the “await” heading the “Task.Run” action.
The nice thing is that you can write “synchronous-like” a piece of code which will be executed “asynchronously”. That’s made by the “magic” pattern “async-await”, and some other simple considerations.
The only annoying thing is that the “real” code will run on a separate thread than the UI’s, thus any direct interaction with the UI must be dispatched to the main thread. If you don’t do that, you’ll get an exception.
Note that I’ve used the MVVM approach to write the app, so the interaction is made with the viewmodel, on which the “real” UI is bound. Any modification to the viewmodel is immediately reflected to the UI.
The demo video.
Okay, here is a short video about the phone-Netduino interaction via Modbus-TCP. Despite the awkward phonemes coming out my mouth, I hope it’s clear enough from the technical perspective!
Conclusions.
I hope this small demo app might be useful for someone, at least as base for something “concrete”.
I guess this experience could be tried on the Fez board, because it seems that the library has been tested successfully. About Gadgeteers or Netduino Go!, I think should be working, but any TCP/IP connection must be available.
As usual, the full sources are hosted in the Codeplex repository: http://cetdevelop.codeplex.com/
Highfield Tales 