Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.

Oh, also, i believe a similar change is required in WriteRegistersRequest at line 59:

data = new byte[ModbusUtils.popByte(queue)];

... should be:

data = new byte[ModbusUtils.popUnsignedByte(queue)];

No problem. Thanks for getting back.

Hi, I'm developing a sensor application pretty similar to what Miguel runs. I stuck with RxTx closing. It works fine but I just can't close it. And what's interesting, it doesn't hang - it just keeps running.

And there is a thing which confuses me the most - I can't find IOLocked!

import java.io.;
import gnu.io.;
import java.util.*;

public class SerialPortHandler {
private SerialPort serialPort;
...

my serialPort just doesn't have this parameter.

And another trouble which I would be so happy to resolve - it takes soooo long to initialize the port - maybe 40 seconds or so.

Miguel, how long does your port initialize? Did you have that problem at all?

See the s/getValue methods in ModbusMaster. You can provide the slave id directly or use a ModbusLocator to encapsulate register details.

Thanks, i will download the new version and check if it works fine. thanks again. :-)

Thanks!

Good point. I added a connection timeout in the Modbus4J implementation. the new jar will ship with the next version of Mango.

A quick description of some of the cool features included in Modbus4J

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.)

In response to the requests for information from developers, we are adding this forum for information about Modbus4J. It is a general purposes Modbus implementation that is used by Mango, but can be used for other purposes as well. So go ahead... everything you wanted to know, ask away!