Hi Jez
The uTasker simulator allows MODBUS RTU/ASCII master/slave and MODBUS TCP master/slave to be simulated/tested.
There are various programs available for testing over TCP - some free ones and some which can be purchased. The wonderful thing about MODBUS TCP however is that Wireshark can interpret the content of such Ethernet frames (displays MODBUS content) and so allows simple verification.
If you look at the uTasker MODBUS User's Guide
http://www.utasker.com/docs/MODBUS/uTasker_MODBUS.PDF (
chapter 20) you will see that the demo MODBUS project actually tests itself by including a TCP master which establishes a link to a TCP slave and tests MODBUS function queries and commands. The MODBUS TCP slave then routes the received queries to a MODBUS serial master which sends them over the serial interface (ASCII or RTU). By looping the COM ports the query arrives at a MODBUS serial slave which finally responds to the query or executes its commands. The answer is then routed back through the reverse path and arrives at the MODBUS TCP master, where it is displayed and the next test in the sequence kick off.
This is only possible in the simulator since it allows the TCP master to send to a slave at its own IP address (which is not normally possible) but the same test works if the master is on a second board (or second simulator) and communicates with a different IP address. The demo project can therefore also be used as a TCP master to test remote TCP slaves (with or without the routing via a further MODBUS serial link) - either in the form of the simulator running or the code running on a real hardware. All transactions can be easily followed by Wireshark.
The uTasker MODBUS module was in fact developed without any further MODBUS SW support; purely allowing it to test itself as described above. However the project was also used in parallel in a small number of Beta projects (these were real industrial developments) where a number of bugs were indeed found along the way and then corrected as appropriate. However the bugs were often things that were also not necessarily obvious even if working with a PC based MODBUS test SW since the communication was generally correct but the content not (the MODBUS protocol analyzer can't tell if the content has an incorrect value - eg. a coil is signaled at state '1' when it was really at state '0') so there was no great need for anything else.
One further advantage of this setup for real development is that when a break point is set in the slave code the TCP communication doesn't breakdown, or the MODBUS master timeout because no response is quickly received (this is because the master is also frozen!!). In fact this is a major advantage in comparison to working with a MODBUS analyzer during this phase of the work. For other tests there is however no reason not to use a MODBUS test program/analyzer if found useful.
There is quite a list of MODBUS test programs on the MODBUS org site:
http://www.modbus.org/tech.phpThe MODBUS solution is otherwise quite (or very?) comprehensive (apart from a couple of public functions which have never been used yet - mainly read and write of records: full list of supported and non-supported public functions ate in Appendix A). I think that the fact that it is fully configurable to perform both master and/or slave functions on multiple serial and/or TCP interfaces, as well as its almost unlimited routing and gateway capabilities (
note that I didn't think up these uses but instead there were quite a variety of such requirements in the first Beta projects alone) makes it very attractive.
The project is also a living project with any new functionality ideas or needs being added when and if possible (for example the project now also supports slave ASCII serial operation on a USB CDC interface -
also a real project requirement, which in fact only required an addition 3 program lines in the MODBUS module itself, but of course the available of CDC class in the uTasker USB section).
Regards
Mark
