| Author |
Message |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 02/10/2008 15:59:17
|
prashant.pro
Initiate
Joined: 02/10/2008 15:46:44
Messages: 1
Offline
|
Hi,
I'm new to mango in general, but i browsed through the code, and had a few queries which i hope someone can answer.
I see the use of modbus4j library, is it similar to jamod or does it work differently? I couldn't find any javadoc associated with modbus4j.
I coded a few lines here and there to test out jamod for Modbus devices over TCP, and wanted to test out modbus4j as well.
Any pointers/samples would really be appreciated.
Thanks.
|
--
Regards,
"Your friendly neighborhood coder" |
|
|
 |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 02/10/2008 17:48:24
|
mlohbihler
Master
![[Avatar]](/forum/images/avatar/eccbc87e4b5ce2fe28308fd9f2a7baf3.png)
Joined: 01/03/2007 22:48:52
Messages: 1847
Offline
|
Check out the Modbus4J project on sourceforge.org. All the source is there. The basic protocol implementation is similar to jamod, but modbus4j fixes a number of jamod issues, and it also adds a very nice usability API to easily handle the common ways in which Modbus is actually used.
|
Best regards,
Matthew Lohbihler |
|
|
 |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 03/03/2009 14:28:21
|
wimpi
Initiate
Joined: 03/03/2009 14:17:37
Messages: 2
Offline
|
mlohbihler wrote:Check out the Modbus4J project on sourceforge.org. All the source is there. The basic protocol implementation is similar to jamod, but modbus4j fixes a number of jamod issues, and it also adds a very nice usability API to easily handle the common ways in which Modbus is actually used.
Given that I am the author of jamod, I find it a bit sad that you had to re-invent the wheel (and also the fact that you copied the OO design and didn't even give jamod any credits).
I even remember fixing problems that you reported (I assume that there aren't so many Matthew Lohbihler's).....
Kind of makes your open source spirit questionable, at least for me
I am constantly updating and fixing jamod and it's being used in industrial and commercial projects with the standard and the facade API (so I can't really follow what your critics about "usability" are referring to).
Anyways, just drop this here so that you and other parties know my side of this story.
Regards,
Dieter
|
|
|
 |
![[Post New]](/forum/templates/default/images/icon_minipost_new.gif) 18/04/2009 17:28:33
|
mlohbihler
Master
![[Avatar]](/forum/images/avatar/eccbc87e4b5ce2fe28308fd9f2a7baf3.png)
Joined: 01/03/2007 22:48:52
Messages: 1847
Offline
|
Hi Dieter,
It's true that I specifically had used jamod for other purposes (some still in use in fact) and had submitted my changes back. For Mango though, we decided that our specific needs would result in changes that were too significant. We also wanted to bring the means of Mango integration in line with other packages that we already had written, such as BACnet4J and an implementation for Spinwave equipment.
It is also true that the OO design, at least with respect to the class structure around requests and responses, is very similar to jamod, but frankly i'm not sure how else it would be done. Still, we will absolutely extend credit to jamod here and anywhere else - such as in the code comments or other - you would like it stated.
Regarding usability, i am very proud to point you to the following:
- ModbusFactory for easily creating master and slave instances
- ProcessImageListener: a callback mechanism that makes the handling of slave write events very simple
- Pluggable exception listeners: no more setting debug=true or dumping errors to System.out. Handle exceptions like you want in client code.
- Controllable slaves: as i recall the jamod slave implementation starts on VM startup and only stops when the VM is killed. In Modbus4J they are completely controllable.
- Node scanning: you can ask the Modbus master to scan for probable active nodes either as a blocking thread or a progressive (and cancel-able) task.
- Simple polling with batch reads that 1) are very intuitive to create, 2) have their responses automatically deconstructed and referenced according to client code, and 3) automatically optimize by making a mimimal number of contiguous requests.
- Simple write commands that will attempt to use optimal requests (such as WriteMaskRegisterRequest) but will failover to more typical requests if the node appears to not support. (This result is also automatically remembered so that it doesn't try the unsupported request again.)
What do you think? Not bad?
Finally, regarding open source spirit, there's no one that suggests that multiple implementations of something is bad. On the contrary, choice is good. And after all, Modbus4J is definitely open source.
|
Best regards,
Matthew Lohbihler |
|
|
 |
|
|