• P
    pentavalle

    Hi, I used Modbus4J for many time, no problem with "old" version still on sourceforge (based on RXTX library), tested hundreds of devices at different speeds, all is ok.

    Just tried to upgrade to 2.0.4 with JSSC and found some problems so I did some tests with a Seneca Z-4AI analog input module using Modbus RTU over RS485 and a Trycom TRP-C08 USB to serial converter (PL2303 chipset) with latest 1.10 prolific drivers in Windows 7 64 bit. This is a setup I used really hundreds of times.
    Most of the time this device didn't answer to my requests, same with a Socomec Diris A10, so I turned on my oscilloscope and captured waveforms on serial line.

    9600 bps, original code (5 ms scale), no response from device:
    [url=http://postimg.org/image/cuswdaplp/]image
    As you can see there's a lot of space between bits, consider that scale is 5x times than following image.

    9600 bps, StreamTransport insted of StreamTransportCharSpaced (1 ms scale), response OK:
    [url=http://postimg.org/image/idee3p6dz/]image
    Spacing is ok and device answered to my request.

    Now testing at higher speeds begins.
    38400 bps, original code (1 ms scale), no response from device:
    [url=http://postimg.org/image/rzfmkyzjt/]image
    Still too much space between bits.

    38400 bps, StreamTransport insted of StreamTransportCharSpaced (1 ms scale), no response from device:
    [url=http://postimg.org/image/75h96q8t9/]image
    Still too much space between bits.

    Looks like there's another problem.... I investigated and found that StreamTransport use write(byte[]) method of OutputStream but JsscSerialPortOutputStream doesn't override that method, so we are using OutputStream class method. Just created this method in JsscSerialPortOutputStream to be able to write complete buffer instead of one byte at a time (like StreamTransportCharSpaced do):

    
    @Override
    public void write(byte[] b) throws IOException {
    	try {
    		if (LOG.isDebugEnabled()) {
    			LOG.debug("Writing bytes: " + StreamUtils.dumpHex(b, 0, b.length));
    		}
    		if ((port != null) && (port.isOpened())) {
    			port.writeBytes(b);
    		}
    	} catch (jssc.SerialPortException e) {
    		throw new IOException(e);
    	}
    }
    
    

    and result was OK ->
    38400 bps, StreamTransport insted of StreamTransportCharSpaced, buffered write (200 us scale), response OK:
    [url=http://postimg.org/image/91tx95dh5/]image
    Spacing is ok and device answered to my request.

    Maybe at higher speeds we need to use internal UART buffer and writing all data in the same request is needed instead of writing byte by byte..

    What do you think about these tests? Have you found any problem communicating with devices with the new version of Modbus4J?

    Edit: Same tests as above with a Moschip 7840 based USB to serial converter shows same results.

    posted in Modbus4J general discussion read more
  • P
    pentavalle

    Hi, I found that using batch requests they are sent one next to each other, but not all devices like this behaviour: crappy devices prefer to have some delay between requests to not stress the CPU. Do you agree? Do you think that adding a programmable delay could be an improvement to Modbus4J?

    posted in Modbus4J general discussion read more
  • P
    pentavalle

    Hi, I tried to compile latest cvs code but I have this error:

    C:\eclipse-workspace\Modbus4J>ant
    Buildfile: C:\eclipse-workspace\Modbus4J\build.xml

    clean:
    [delete] Deleting directory C:\eclipse-workspace\Modbus4J\target

    compile:
    [mkdir] Created dir: C:\eclipse-workspace\Modbus4J\target
    [javac] C:\eclipse-workspace\Modbus4J\build.xml:17: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds
    [javac] Compiling 104 source files to C:\eclipse-workspace\Modbus4J\target
    [javac] C:\eclipse-workspace\Modbus4J\src\com\serotonin\modbus4j\ModbusMaster.java:261: cannot find symbol
    [javac] symbol : method setDiscardDataDelay(int)
    [javac] location: class com.serotonin.messaging.MessageControl
    [javac] conn.setDiscardDataDelay(getDiscardDataDelay());
    [javac] ^
    [javac] 1 error

    BUILD FAILED
    C:\eclipse-workspace\Modbus4J\build.xml:17: Compile failed; see the compiler error output for details.

    Total time: 1 second

    C:\eclipse-workspace\Modbus4J>

    Looks like seroUtils.jar was updated in cvs, but not in synch with Modbus4J code :-)

    posted in Modbus4J general discussion read more
  • P
    pentavalle

    Just taking a look at 1.13 release in CVS, I have seen that ModbusFactory.createRtuMaster and ModbusFactory.createAsciiMaster now requires an int "concurrency" parameter.
    This parameter could be SerialMaster.SYNC_TRANSPORT, SerialMaster.SYNC_SLAVE or SerialMaster.SYNC_FUNCTION and modify the behaviour of SerialWaitingRoomKeyFactory.
    What's the difference between those 3 values?

    posted in Modbus4J general discussion read more
  • P
    pentavalle

    Hi, I want to get latest source code for modbus4j but when i execute
    cvs -d:pserver:anonymous@modbus4j.cvs.sourceforge.net:/cvsroot/modbus4j login
    as found in http://sourceforge.net/projects/modbus4j/develop I get a "connection refused" error, and even ViewVC on http://modbus4j.cvs.sourceforge.net/modbus4j send a 404 error.
    Is there a problem with the repository?

    posted in Modbus4J general discussion read more
  • P
    pentavalle

    Here they are!
    Same device, same USB converter, Ubuntu 13.10.

    9600 bps, original code, response OK:
    [url=http://postimg.org/image/537j754y7/]image

    9600 bps, StreamTransport instead of StreamTransportCharSpaced, response OK:
    [url=http://postimg.org/image/tpifzy34x/]image

    9600 bps, StreamTransport insted of StreamTransportCharSpaced, buffered write, response OK:
    [url=http://postimg.org/image/5yofzhjfr/]image

    38400 bps, original code, no response from device:
    [url=http://postimg.org/image/euz83fa1z/]image

    38400 bps, StreamTransport insted of StreamTransportCharSpaced, response OK:
    [url=http://postimg.org/image/oqfn1doaz/]image

    38400 bps, StreamTransport insted of StreamTransportCharSpaced, buffered write, response OK:
    [url=http://postimg.org/image/5t64gnlz7/]image

    Edit: test machine was an Intel N2600, previous tests on Windows were on a Intel Core I5 3230M

    For the NPE consider I had that only with PL2303 chip, that receives packets in chunks, not all in one.

    Just a question: why did you decide to use JSSC insted of, for example, nrjavaserial? nrjavaserial is compatible with javax.comm, while JSSC is completely different, so a port was necessary.

    posted in Modbus4J general discussion read more
  • P
    pentavalle

    Just left out one last thing: at 38400bps I have many NPEs in JsscSerialPortInputStream:

    
    byte[] buffer = this.port.readBytes();
    for (byte element : buffer) {
        this.dataStream.put(element);
    }
    
    

    Because buffer is null and, as stated in Javadoc for readBytes() method: If input buffer is empty null will be returned, else byte array with all data from port
    So it would be better to check for null before cycling elements in buffer or early checking event.getEventValue() because in case of NPE is 0 (means 0 byte in buffer).

    At least this is what I have with my PL2303 converter!

    Edit: Testing with a Moschip 7840 based USB to serial converter doesn't generate NPE. Buffer isn't empty when there's an RX char event.

    posted in Modbus4J general discussion read more
  • P
    pentavalle

    Hi, I used Modbus4J for many time, no problem with "old" version still on sourceforge (based on RXTX library), tested hundreds of devices at different speeds, all is ok.

    Just tried to upgrade to 2.0.4 with JSSC and found some problems so I did some tests with a Seneca Z-4AI analog input module using Modbus RTU over RS485 and a Trycom TRP-C08 USB to serial converter (PL2303 chipset) with latest 1.10 prolific drivers in Windows 7 64 bit. This is a setup I used really hundreds of times.
    Most of the time this device didn't answer to my requests, same with a Socomec Diris A10, so I turned on my oscilloscope and captured waveforms on serial line.

    9600 bps, original code (5 ms scale), no response from device:
    [url=http://postimg.org/image/cuswdaplp/]image
    As you can see there's a lot of space between bits, consider that scale is 5x times than following image.

    9600 bps, StreamTransport insted of StreamTransportCharSpaced (1 ms scale), response OK:
    [url=http://postimg.org/image/idee3p6dz/]image
    Spacing is ok and device answered to my request.

    Now testing at higher speeds begins.
    38400 bps, original code (1 ms scale), no response from device:
    [url=http://postimg.org/image/rzfmkyzjt/]image
    Still too much space between bits.

    38400 bps, StreamTransport insted of StreamTransportCharSpaced (1 ms scale), no response from device:
    [url=http://postimg.org/image/75h96q8t9/]image
    Still too much space between bits.

    Looks like there's another problem.... I investigated and found that StreamTransport use write(byte[]) method of OutputStream but JsscSerialPortOutputStream doesn't override that method, so we are using OutputStream class method. Just created this method in JsscSerialPortOutputStream to be able to write complete buffer instead of one byte at a time (like StreamTransportCharSpaced do):

    
    @Override
    public void write(byte[] b) throws IOException {
    	try {
    		if (LOG.isDebugEnabled()) {
    			LOG.debug("Writing bytes: " + StreamUtils.dumpHex(b, 0, b.length));
    		}
    		if ((port != null) && (port.isOpened())) {
    			port.writeBytes(b);
    		}
    	} catch (jssc.SerialPortException e) {
    		throw new IOException(e);
    	}
    }
    
    

    and result was OK ->
    38400 bps, StreamTransport insted of StreamTransportCharSpaced, buffered write (200 us scale), response OK:
    [url=http://postimg.org/image/91tx95dh5/]image
    Spacing is ok and device answered to my request.

    Maybe at higher speeds we need to use internal UART buffer and writing all data in the same request is needed instead of writing byte by byte..

    What do you think about these tests? Have you found any problem communicating with devices with the new version of Modbus4J?

    Edit: Same tests as above with a Moschip 7840 based USB to serial converter shows same results.

    posted in Modbus4J general discussion read more
  • P
    pentavalle

    Hi, I found that using batch requests they are sent one next to each other, but not all devices like this behaviour: crappy devices prefer to have some delay between requests to not stress the CPU. Do you agree? Do you think that adding a programmable delay could be an improvement to Modbus4J?

    posted in Modbus4J general discussion read more