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!
Rogue Engineering Inc
Rogue Engineering Inc is a quality manufacturer of electronics and
software products for industrial and niche markets.