Modbus software design guidelines

Hi,
apologies if this is posted incorrectly.
I am designing an application interface for a modbus capable device.
I have my communications working, using jamod and javax.comm, so now I
need some advice on designing a flexible framework.
I would like references for the best way to monitor a device of this type. I would like to provide an event driven interface over top of my transport layer.
All help appreciated.
Ben.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Ben,
Are you writing an interface for a specific device? Generally, your interface will be specific to the device you are talking to, as for what kind of events to support.
Since you wrote the communications framework in Java, I would recommend setting up the interface between your communications framework java code and your GUI as a TCP/IP client/server. The GUI can be written in any language you want this way, and run as a separate process to keep the user from being able to bog down the communications thread. There are a lot of java examples on the web of writing your GUI in a separate process or thread from your main application code. Do a search on java tutorial thread gui or something like that. If you write your GUI in java as well, or you use multiple threads in the communications code, check out the java.util.concurrent class for multithreading and interprocess/interthread communications tools.
As for the event driven interface, you have two choices: 1. You can have your user interface poll the device's registers through the communications code continuously on a schedule and react to the responses from each poll cycle, inserting extra user requested reads and writes as they are generated by the user interface, or not polling at all and only sending user driven commands. This is the simplest to implement in code, but as all communications then originate in the user interface, this can bog down if you are trying to do a lot communications quickly while still reacting to keyboard and mouse input. You can see an example of this type of software in our Modbus Test Pro Software, available from our distributor rawiq.com In that software, I created a communications framework where my user interface just had to call a function like myresultlist = MBFcn3 ( myaddr, startreg, numregs, &errcode ) and the communications framework took care of the rest.
2. Implement a polling system in the communications code with triggers to alert the user interface process when values change on the device. This is more robust design for fast communications processing, especially when communicating and polling multiple devices on varying schedules, complete with failure handling and retries. I have implemented a similar system before in our java based modbus device server, and it was fairly complicated to write properly. If you go this route, you will definitely want to make use of multithreading with thread pooling to keep things from locking up while waiting for other things to happen.
Hope this helps!
Tim Kirk Rogue Engineering Inc www.rogue-engr.com Rogue Engineering Inc is a quality manufacturer of electronics and software products for industrial and niche markets.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
Hi Tim,
Yep, the whole lot will be java based, and I think option 2 is what we are looking at, since for the most part we are monitoring the device(s) for changes. We do need to allow UI driven read/writes also, but I am sure we can handle that within the same threading schedule.
Ideally we would like to keep the framework open enough to allow configuration of the registers being monitored, easy then switch the data implementation (the device). This can be left to the application.
So the first step, as you have pointed out, is the polling mechanism, and from there the propagation of events.
Thanks for your help,
<bb />
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.