From pashmina.mukhi at patni.com Thu Sep 2 08:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu Sep 2 08:11:47 2004 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Skipped content of type multipart/alternative From taj at www.linux.org.uk Wed Sep 8 02:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed Sep 8 02:37:50 2004 Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj@www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 20:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Wed Sep 8 03:28:48 2004 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 14:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed Sep 8 14:54:56 2004 Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj@www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.linuxgrrls.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0001.bin From eugene_melekhov at mail.ru Thu Sep 9 08:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu Sep 9 12:10:23 2004 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 12:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu Sep 9 12:18:27 2004 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 14:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu Sep 9 14:00:56 2004 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 13:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon Sep 13 13:25:46 2004 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc@exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 17:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon Sep 13 17:44:37 2004 Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj@www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 17:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon Sep 13 17:47:13 2004 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 19:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon Sep 13 19:18:11 2004 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj@www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 21:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon Sep 13 21:37:40 2004 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 23:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon Sep 13 23:28:46 2004 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From j.d.charlton at ieee.org Wed Sep 15 00:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue Sep 14 23:56:31 2004 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 23:51:23 2004 From: bst_co at yahoo.com (bst) Date: Wed Sep 15 00:12:48 2004 Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Wed Sep 15 01:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed Sep 15 01:02:52 2004 Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj@www.linux.org.uk From pashmina.mukhi at patni.com Wed Sep 15 05:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed Sep 15 05:22:12 2004 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Skipped content of type multipart/alternative From taj at www.linux.org.uk Wed Sep 15 14:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed Sep 15 14:06:20 2004 Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 16:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed Sep 15 16:05:34 2004 Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj@www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj@www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 16:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed Sep 15 16:43:47 2004 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.linuxgrrls.org/pipermail/rxtx/attachments/20040915/d5081611/echotest.bin From p_edson at yahoo.com Thu Sep 16 16:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu Sep 16 16:39:30 2004 Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 17:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu Sep 16 17:41:15 2004 Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj@www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 15:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri Sep 17 15:43:59 2004 Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Tue Sep 21 00:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Tue Sep 21 00:15:44 2004 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 13:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue Sep 21 13:24:24 2004 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.linuxgrrls.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment.html From dmarkman at mac.com Thu Sep 23 04:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu Sep 23 04:24:32 2004 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 09:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu Sep 23 09:18:13 2004 Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 15:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu Sep 23 15:14:00 2004 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 22:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon Sep 27 22:38:55 2004 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj@www.linux.org.uk From dmarkman at mac.com Mon Sep 27 23:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon Sep 27 23:30:55 2004 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Tue Sep 28 00:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue Sep 28 00:03:36 2004 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 08:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Fri Jun 3 17:46:42 2005 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Skipped content of type multipart/alternative From taj at www.linux.org.uk Wed Sep 8 02:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:42 2005 Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj@www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 20:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Fri Jun 3 17:46:42 2005 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 14:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:43 2005 Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj@www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0002.bin From eugene_melekhov at mail.ru Thu Sep 9 08:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Fri Jun 3 17:46:43 2005 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 12:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 3 17:46:43 2005 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 14:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:43 2005 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 13:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Fri Jun 3 17:46:43 2005 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc@exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 17:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:43 2005 Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj@www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 17:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Fri Jun 3 17:46:43 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 19:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:43 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj@www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 21:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Fri Jun 3 17:46:43 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 23:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:44 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From j.d.charlton at ieee.org Wed Sep 15 00:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Fri Jun 3 17:46:44 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 23:51:23 2004 From: bst_co at yahoo.com (bst) Date: Fri Jun 3 17:46:44 2005 Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Wed Sep 15 01:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:44 2005 Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj@www.linux.org.uk From pashmina.mukhi at patni.com Wed Sep 15 05:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Fri Jun 3 17:46:44 2005 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Skipped content of type multipart/alternative From taj at www.linux.org.uk Wed Sep 15 14:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:44 2005 Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 16:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:44 2005 Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj@www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj@www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 16:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Fri Jun 3 17:46:44 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0002.bin From p_edson at yahoo.com Thu Sep 16 16:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri Jun 3 17:46:44 2005 Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 17:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj@www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 15:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Tue Sep 21 00:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 13:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://pixie.strangenoises.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment.htm From dmarkman at mac.com Thu Sep 23 04:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 09:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 15:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 22:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj@www.linux.org.uk From dmarkman at mac.com Mon Sep 27 23:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Tue Sep 28 00:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 17:46:45 2005 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 08:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Fri Jun 3 18:09:05 2005 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Skipped content of type multipart/alternative From taj at www.linux.org.uk Wed Sep 8 02:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:05 2005 Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj@www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 20:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Fri Jun 3 18:09:05 2005 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 14:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj@www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0003.bin From eugene_melekhov at mail.ru Thu Sep 9 08:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 12:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 14:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 13:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc@exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 17:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj@www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 17:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 19:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj@www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 21:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 23:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:06 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From j.d.charlton at ieee.org Wed Sep 15 00:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 23:51:23 2004 From: bst_co at yahoo.com (bst) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Wed Sep 15 01:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj@www.linux.org.uk From pashmina.mukhi at patni.com Wed Sep 15 05:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Skipped content of type multipart/alternative From taj at www.linux.org.uk Wed Sep 15 14:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj@www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 16:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj@www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj@www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 16:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://pixie.strangenoises.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0003.bin From p_edson at yahoo.com Thu Sep 16 16:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 17:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj@www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 15:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri Jun 3 18:09:07 2005 Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Tue Sep 21 00:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 13:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://pixie.strangenoises.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0001.htm From dmarkman at mac.com Thu Sep 23 04:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 09:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 15:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 22:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj@www.linux.org.uk From dmarkman at mac.com Mon Sep 27 23:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj@www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Tue Sep 28 00:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Fri Jun 3 18:09:08 2005 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj@www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx@linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx@linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj@www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0395.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0395.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0395.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0395.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0395.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0396.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0396.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0396.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0396.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0396.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0397.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0397.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0397.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0397.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0397.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0398.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0398.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0398.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0398.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0398.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0399.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0399.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0399.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0399.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0399.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0400.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0400.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0400.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0400.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0400.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0401.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0401.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0401.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0401.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0401.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0402.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0402.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0402.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0402.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0402.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0403.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0403.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0403.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0403.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0403.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0404.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0404.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0404.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0404.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0404.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0001.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0001.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0001.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0001.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0001.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0002.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0002.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0002.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0002.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0002.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0003.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0003.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0003.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0003.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0003.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0004.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0004.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0004.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0004.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0004.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0005.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0005.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0005.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0005.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0005.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0006.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0006.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0006.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0006.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0006.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0007.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0007.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0007.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0007.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0007.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0008.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0008.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0008.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0008.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0008.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0009.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0009.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0009.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0009.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0009.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0010.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0010.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0010.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0010.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0010.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0001.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0001.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0001.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0001.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0001.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0002.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0002.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0002.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0002.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0002.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0003.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0003.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0003.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0003.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0003.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0004.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0004.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0004.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0004.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0004.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0005.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0005.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0005.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0005.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0005.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0006.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0006.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0006.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0006.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0006.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0007.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0007.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0007.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0007.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0007.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0008.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0008.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0008.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0008.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0008.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0009.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0009.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0009.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0009.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0009.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0010.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0010.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0010.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0010.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0010.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0001.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0001.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0001.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0001.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0001.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0002.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0002.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0002.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0002.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0002.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0003.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0003.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0003.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0003.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0003.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0004.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0004.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0004.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0004.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0004.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0005.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0005.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0005.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0005.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0005.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0006.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0006.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0006.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0006.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0006.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0007.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0007.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0007.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0007.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0007.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0008.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0008.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0008.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0008.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0008.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0009.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0009.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0009.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0009.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0009.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0010.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0010.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0010.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0010.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0010.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0011.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0011.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0011.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0011.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0011.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0012.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0012.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0012.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0012.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0012.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0013.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0013.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0013.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0013.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0013.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0014.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0014.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0014.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0014.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0014.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0015.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0015.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0015.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0015.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0015.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0016.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0016.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0016.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0016.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0016.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0017.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0017.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0017.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0017.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0017.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0018.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0018.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0018.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0018.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0018.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0019.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0019.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0019.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0019.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0019.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0020.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0020.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0020.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0020.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0020.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0021.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0021.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0021.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0021.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0021.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0022.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0022.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0022.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0022.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0022.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0023.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0023.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0023.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0023.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0023.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0024.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0024.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0024.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0024.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0024.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0025.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0025.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0025.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0025.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0025.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0026.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0026.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0026.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0026.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0026.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0027.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0027.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0027.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0027.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0027.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0028.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0028.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0028.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0028.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0028.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0029.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0029.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0029.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0029.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0029.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0030.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0030.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0030.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0030.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0030.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0031.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/msbuild-0031.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0031.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/echotest-0031.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot@drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0031.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0032.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/attachment.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0032.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/attachment.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot at drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0032.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the MacOSX version. I don't have access to a MacOSX platform so have been relying on the binaries found in the MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had reports from users on MacOSX that when they try to use the serial connection they get the following error: Devel Library ========================================= Native lib Version = RXTX-2.1-7pre12 Java lib Version = RXTX-2.1-7pre17 WARNING: RXTX Version mismatch Jar version = RXTX-2.1-7pre17 native lib Version = RXTX-2.1-7pre12 Is there anywhere I can download binaries for the pre17 rather than pre12 version? I am assuming that is the problem, but any fix would be appreciated. Thanks very much, Jo. From dmarkman at mac.com Thu Sep 23 08:22:45 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Thu, 23 Sep 2004 10:22:45 -0400 Subject: [Rxtx] Are latest MacOSX binaries available? In-Reply-To: References: Message-ID: <09B5449F-0D6C-11D9-A750-000A95DA5E9C@mac.com> I committed latest files from my CW directory into CVS so it should work On Sep 23, 2004, at 4:24 AM, Jo Wood wrote: > I have been sucessfully using RXTX 2.1-7pre17 for a while now on my > windows and Linux platform without problems. I have been distributing > the > binararies with my software that connects to GPS via the serial port > (http://www.landserf.org) for Windows, Linux and MacOSX platforms. > > The problem I have is with the MacOSX version. I don't have access to a > MacOSX platform so have been relying on the binaries found in the > MACOSX_IDE\CW directory of the 2.1.7pre17 distribution. I have had > reports > from users on MacOSX that when they try to use the serial connection > they > get the following error: > > Devel Library > ========================================= > Native lib Version = RXTX-2.1-7pre12 > Java lib Version = RXTX-2.1-7pre17 > WARNING: RXTX Version mismatch > Jar version = RXTX-2.1-7pre17 > native lib Version = RXTX-2.1-7pre12 > > > Is there anywhere I can download binaries for the pre17 rather than > pre12 > version? I am assuming that is the problem, but any fix would be > appreciated. > > Thanks very much, > > Jo. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 15:38:53 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 27 Sep 2004 22:38:53 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: On Wed, 22 Sep 2004, Dmitry Markman wrote: > maybe somebody remembers > > how that happened that > lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > distribution) > #if defined(__APPLE__) > # define DEVICEDIR "/dev/" > /*# define LOCKDIR "/var/spool/uucp"*/ > # define LOCKDIR "/var/lock" > # define LOCKFILEPREFIX "LK." > # define UUCP > > that's why librxtxSerial.jnilib, that installed by my installer > doesn't work > > maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > /var/lock? > > if there is a serious reason then I'll change my installer too: > > if [ ! -d /var/lock ] > then > sudo mkdir /var/lock > fi > > sudo chgrp uucp /var/lock > sudo chmod 775 /var/lock > if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > /dev/null` ] > then > sudo niutil -mergeprop / /groups/uucp users $curruser > fi > > but that doesn't look good to me The only thing I can think of is maybe I changed that while looking at the wrong OS. Just go with whatever looks right on the host system. If Mac OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may do something else. http://www.pathname.com/fhs/ http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES -- Trent Jarvi taj at www.linux.org.uk From dmarkman at mac.com Mon Sep 27 16:30:53 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Mon, 27 Sep 2004 18:30:53 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: well, fhs guys insist that lock folder should be /var/lock AFAIK Apple doesn't provide any recommendation for MAC OS X regarding lock directory meanwhile I'd prefer to stick to the /var/spool/uucp because many users already use that folder from other hand that could be changed very easy one thing: if we will use /var/lock folder why we have to use uucp group? if we won't use uucp group what we'll use instead? and all related setting for permissions thanks On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > On Wed, 22 Sep 2004, Dmitry Markman wrote: > >> maybe somebody remembers >> >> how that happened that >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X >> distribution) >> #if defined(__APPLE__) >> # define DEVICEDIR "/dev/" >> /*# define LOCKDIR "/var/spool/uucp"*/ >> # define LOCKDIR "/var/lock" >> # define LOCKFILEPREFIX "LK." >> # define UUCP >> >> that's why librxtxSerial.jnilib, that installed by my installer >> doesn't work >> >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the >> /var/lock? >> >> if there is a serious reason then I'll change my installer too: >> >> if [ ! -d /var/lock ] >> then >> sudo mkdir /var/lock >> fi >> >> sudo chgrp uucp /var/lock >> sudo chmod 775 /var/lock >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > >> /dev/null` ] >> then >> sudo niutil -mergeprop / /groups/uucp users $curruser >> fi >> >> but that doesn't look good to me > > The only thing I can think of is maybe I changed that while looking at > the > wrong OS. Just go with whatever looks right on the host system. If > Mac > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > do > something else. > > http://www.pathname.com/fhs/ > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > -- > Trent Jarvi > taj at www.linux.org.uk > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > Dmitry Markman From taj at www.linux.org.uk Mon Sep 27 17:03:34 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Tue, 28 Sep 2004 00:03:34 +0100 (BST) Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> Message-ID: I'm not sure what standard Mac OS X chooses to follow. Thats the nice thing about standards, there are so many to choose from. With FHS, the group is not defined. Some use group lock, others group uucp. lock is how the Linux guys are going. In other words the vendor (Apple) should specify what the group is on their OS. /var/spool/uucp is from back when people did "unix to unix copy" over serial ports. So there is old history associated with the directory. If you are just creating the directory and group, I'd go with the FHS or specify a definitive link if another location used. Then we can point to the standard followed on Mac and if another vendor has another opinion it can just be worked out by having Apple specify what standard they like. Its not so important that we use a directory I like. What we are trying to do is agree with other software developers. If minicom locks the serial port in /var/lock/uucp and rxtx locks the serial port in /var/lock, the entire point of lockfiles is defeated. This is why you see some funny code in rxtx looking in many directories for lockfiles. On Mon, 27 Sep 2004, Dmitry Markman wrote: > well, fhs guys insist that lock folder should be > /var/lock > > > AFAIK Apple doesn't provide any recommendation for MAC OS X regarding > lock directory > meanwhile I'd prefer to stick to the /var/spool/uucp > > because many users already use that folder > > from other hand that could be changed very easy > > one thing: if we will use /var/lock folder why we have to use uucp > group? > if we won't use uucp group what we'll use instead? > > and all related setting for permissions > > thanks > > > > On Sep 27, 2004, at 5:38 PM, Trent Jarvi wrote: > > > On Wed, 22 Sep 2004, Dmitry Markman wrote: > > > >> maybe somebody remembers > >> > >> how that happened that > >> lock directory for Apple was changed to the /var/lock ? (only in 2.0.X > >> distribution) > >> #if defined(__APPLE__) > >> # define DEVICEDIR "/dev/" > >> /*# define LOCKDIR "/var/spool/uucp"*/ > >> # define LOCKDIR "/var/lock" > >> # define LOCKFILEPREFIX "LK." > >> # define UUCP > >> > >> that's why librxtxSerial.jnilib, that installed by my installer > >> doesn't work > >> > >> maybe there is a reason to change LOCKDIR from /var/spool/uucp to the > >> /var/lock? > >> > >> if there is a serious reason then I'll change my installer too: > >> > >> if [ ! -d /var/lock ] > >> then > >> sudo mkdir /var/lock > >> fi > >> > >> sudo chgrp uucp /var/lock > >> sudo chmod 775 /var/lock > >> if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > > >> /dev/null` ] > >> then > >> sudo niutil -mergeprop / /groups/uucp users $curruser > >> fi > >> > >> but that doesn't look good to me > > > > The only thing I can think of is maybe I changed that while looking at > > the > > wrong OS. Just go with whatever looks right on the host system. If > > Mac > > OS X follows the FHS, then "/var/spool/uucp" is very wrong but Mac may > > do > > something else. > > > > http://www.pathname.com/fhs/ > > http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES > > > > -- > > Trent Jarvi > > taj at www.linux.org.uk > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > > Dmitry Markman > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Thu Sep 2 01:27:09 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Thu, 2 Sep 2004 12:57:09 +0530 Subject: [Rxtx] FW: Problem in writing to SerialOutputStream Message-ID: <012601c490be$429fee60$036ad103@patni.com> Hi, Using RxTx, after i open a port and try to write a message on the output stream, sometimes i get this output: java.io.IOException: Resource temporarily unavailable in writeArray at gnu.io.RXTXPort.writeArray(Native Method) at gnu.io.RXTXPort$SerialOutputStream.write(RXTXPort.java:1131)....... This doesn't occur all the time...,...at times i am able to successfully write a message onto the stream. What can be the possible reason for this and how can i solve the above error? Thanks & Regards, Pashmina Mukhi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040902/da1573d7/attachment-0033.html From taj at www.linux.org.uk Tue Sep 7 19:42:41 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 02:42:41 +0100 (BST) Subject: [Rxtx] Services back up Message-ID: We have had some problems with the mail-list server and the cvs server. Both appear to be back up. First time in a long time we have had problems. They are on two different domains. The mail-list problem was mainly subscription/unsubscription and administration. CVS was just down with a HD failure. Sometimes I think entropy knows when you are not looking. I'll be going through my email and letting people know we are up. -- Trent Jarvi taj at www.linux.org.uk From copterchris at yahoo.com Thu Sep 2 13:21:23 2004 From: copterchris at yahoo.com (Chris Norris) Date: Thu, 2 Sep 2004 12:21:23 -0700 (PDT) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories Message-ID: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Hi, I'm trying to see if I can get RXTX to work without needing to copy comm.jar, javax.comm.properties and the corresponding native library into the various Java directories and, instead, have them in a single user-created directory somewhere. I have achieved this on Windows with the normal Java COMM libraries via manipulations of the classpath but the same things tried with RXTX don't seem to work. Has anyone tried this? Any suggestions for what might be required in Mac OS X and LINUX environments to achieve this? Thanks, Chris _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From taj at www.linux.org.uk Wed Sep 8 07:59:54 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 8 Sep 2004 14:59:54 +0100 (BST) Subject: [Rxtx] MS Visual C Builds, Re[3]: rxtx problems (fwd) Message-ID: Eugene has managed to build rxtxSerial.dll with Microsoft tools. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 8 Sep 2004 17:23:10 +0400 From: Eugene Melekhov To: Trent Jarvi Subject: Re[3]: rxtx problems Trent, I've made first attempt to compile rxtx with Microsoft Visual C. It seems that serial part at least works ok. I didn't try to test parallel, but now I can debug my Eclipse plugin just fine. Thank you for help. I've attached Makefile for MS compiler and a couple of source files that I've changed slightly. Take a look. You can include this in the distributive if you wish. -- Eugene Melekhov Object Tools http://www.object-tools.com -------------- next part -------------- A non-text attachment was scrubbed... Name: msbuild.zip Type: application/x-zip-compressed Size: 42861 bytes Desc: Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040908/73bb8de1/attachment-0001.bin From eugene_melekhov at mail.ru Thu Sep 9 01:22:35 2004 From: eugene_melekhov at mail.ru (Eugene Melekhov) Date: Thu, 9 Sep 2004 11:22:35 +0400 Subject: [Rxtx] Re: Running RXTX without installing JARs and libraries to normal Message-ID: <1708148483.20040909112235@mail.ru> Chris, You can try java -classpath -Djava.library.path= -- Eugene From moritz.gmelin at gmx.de Thu Sep 9 05:23:37 2004 From: moritz.gmelin at gmx.de (Moritz Gmelin) Date: Thu, 9 Sep 2004 13:23:37 +0200 Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: <20040902192123.23168.qmail@web52002.mail.yahoo.com> References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: Hi, I've posted a Class LibLoader a while ago, that can extract the needed .DLL, .so, or .jnilib file from within the JAR-Archive, write it to a temporary directory and load it via System.load() as a native Library. That way you don't need any installation at all. Just include RXTX.jar into your CLASSPATH and be happy. Greetings Moritz Am 02.09.2004 um 21:21 schrieb Chris Norris: > > Hi, > > I'm trying to see if I can get RXTX to work without > needing to copy comm.jar, javax.comm.properties and > the corresponding native library into the various Java > directories and, instead, have them in a single > user-created directory somewhere. > > I have achieved this on Windows with the normal Java > COMM libraries via manipulations of the classpath but > the same things tried with RXTX don't seem to work. > > Has anyone tried this? Any suggestions for what might > be required in Mac OS X and LINUX environments to > achieve this? > > Thanks, > > Chris > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > From taj at www.linux.org.uk Thu Sep 9 07:06:15 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 9 Sep 2004 14:06:15 +0100 (BST) Subject: [Rxtx] Running RXTX without installing JARs and libraries to normal directories In-Reply-To: References: <20040902192123.23168.qmail@web52002.mail.yahoo.com> Message-ID: On Thu, 9 Sep 2004, Moritz Gmelin wrote: > Hi, > > I've posted a Class LibLoader a while ago, that can extract the needed > .DLL, .so, or .jnilib file from within the JAR-Archive, > write it to a temporary directory and load it via System.load() as a > native Library. That way you don't need any installation at all. Just > include RXTX.jar into your CLASSPATH and be happy. > > Greetings > > Moritz The post can be found here: http://marc.theaimsgroup.com/?l=rxtx&m=107722630723569&w=2 > > Am 02.09.2004 um 21:21 schrieb Chris Norris: > > > > > Hi, > > > > I'm trying to see if I can get RXTX to work without > > needing to copy comm.jar, javax.comm.properties and > > the corresponding native library into the various Java > > directories and, instead, have them in a single > > user-created directory somewhere. > > > > I have achieved this on Windows with the normal Java > > COMM libraries via manipulations of the classpath but > > the same things tried with RXTX don't seem to work. > > > > Has anyone tried this? Any suggestions for what might > > be required in Mac OS X and LINUX environments to > > achieve this? > > > > Thanks, > > > > Chris > > > > > > > > > > _______________________________ > > Do you Yahoo!? > > Win 1 of 4,000 free domain names from Yahoo! Enter now. > > http://promotions.yahoo.com/goldrush > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > > > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From colinc at exsoft.com.au Mon Sep 13 06:31:53 2004 From: colinc at exsoft.com.au (Colin Canfield) Date: Mon, 13 Sep 2004 22:31:53 +1000 Subject: [Rxtx] Any way to startup with polling comm ports. Message-ID: Is there any way to disable the polling of comm ports when the library starts up ? I have a system with a lot of virtual devices and polling the comm ports does all sorts of weird things ? Thanks, Colin ---------------------------------------------------------------------- Colin Canfield colinc at exsoft.com.au Consultant Explorative Software Pty ltd 0412 197 943 From taj at www.linux.org.uk Mon Sep 13 10:50:58 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 17:50:58 +0100 (BST) Subject: [Rxtx] Any way to startup with polling comm ports. In-Reply-To: References: Message-ID: On Mon, 13 Sep 2004, Colin Canfield wrote: > Is there any way to disable the polling of comm ports when the library > starts up ? I have a system with a lot of virtual devices and polling > the comm ports does all sorts of weird things ? > > Thanks, Colin > > The INSTALL file with the source code explains how to override this: Q. How does rxtx detect ports? Can I override it? rxtx tries to detect ports on by scanning /dev for files matching any of a set of known-good prefixes, such as 'ttyS', 'ttym', and so on. Any ones that exist, are supposed to be good for the current operating system, and that can be read and written are offered back from CommPortIdentifier.getPortIdentifiers(), and only these can be used as ports. If you wish, you can set the system properties gnu.io.rxtx.SerialPorts and gnu.io.rxtx.ParallelPorts. If either of these is set, then no scanning will be carried out and only the specified ports will be available. You can use this to make one platform look like another, to restrict Java access to ports, or possibly for other reasons. For example java -Dgnu.io.rxtx.SerialPorts=/dev/cua/a:/dev/cua/b com.foo.MyApp will look kind of like Solaris, if you have created the appropriate device nodes. A note on Linux port enumeration. We have set most ports aside. Once the number of possible devices started getting into the thousands, checking them all made little sense. Look in RXTXCommDriver.java and search for Linux. You will see that only /dev/ttyS* is searched but the possible addition ports that can be used are listed under it. Just copy the few you need. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 10:53:33 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 12:53:33 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: Message-ID: <200409131253.33248.j.d.charlton@ieee.org> I appreciate help with this and advice. I have just installed the latest rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ receive on an RS-485 network. I enabled debug and trace messages in SerialImpl.c. The RS-485 modbus RTU message is sent with the following java sequence: synchronized (m_ByteOut) { .... code to create the message and CRC bytes... //write message byte[] buf = m_ByteOut.getBuffer(); len = m_ByteOut.size(); m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); m_ByteOut.reset(); // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { // 500 msec timeout interval // longer interval doesn't help System.err.println("Error: Transmit echo not received."); } } } m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an byte array OutputStream sub class for encapsulating the byte array used for the modbus message. This code is in the jamod SourceForge open source project. These are the generated trace/debug messages: INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. This problem is more noticable with a slower baud rate. These messages were generated with 9600 baud. The problem goes away most of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo jumper 'on'. The problem occurs more frequently with about every other packet sent at 9600 baud, but mostly goes away at 57600 baud. This code is called from an RMI server, but the problem is occurring with only one client present. I appreciate any advice/insights others have to help resolve this problem. --John PS: I did notice that there is an RS485Imp.c and associated RS485Port.java class. I am not currently using the RS485 specific class, because I think all I need to do with the modbus protocol is to process the echo. Since the modbus protocol is master/slave I don't need to process collisions or tokens. I have browsed the javadocs on the RS485Port, but so far have not modified the code to use RS485Port. Please advize if there is a benifit in using RS485Port with this configuration. From taj at www.linux.org.uk Mon Sep 13 12:24:33 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 19:24:33 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131253.33248.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > I appreciate help with this and advice. I have just installed the latest > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > receive on an RS-485 network. I enabled debug and trace messages in > SerialImpl.c. The RS-485 modbus RTU message is sent with the following java > sequence: > > synchronized (m_ByteOut) { > .... code to create the message and CRC bytes... > > //write message > byte[] buf = m_ByteOut.getBuffer(); > len = m_ByteOut.size(); > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > m_ByteOut.reset(); > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { // 500 msec timeout interval > // longer interval doesn't help > System.err.println("Error: Transmit echo not received."); > } > } > } > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. m_ByteOut is an > byte array OutputStream sub class for encapsulating the byte array used for > the modbus message. This code is in the jamod SourceForge open source > project. > > These are the generated trace/debug messages: > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not received. The clearInput() is not part of rxtx so I'm wondering if maybe it is timing out prior to the 500 ms. That would be what I would investigate first. The timings (500 ms?) are long. Can you confirm that it does indeed work? What happens if you set the timing to something you could measure with a watch? What happens if you sleep for a second and then try the clearInput()? One thing thats different between win32 and Linux is the resolution for timeouts in windows has another significant digit. I dont think thats the problem here, but I do suspect there is some sort of problem with the timeouts. I dont see where RXTX reports the timeout was changed. hmm. But that could just be the amount of debugging you asked for. > > This problem is more noticable with a slower baud rate. These messages were > generated with 9600 baud. The problem goes away most of the time at 57600 > baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which is a RS-232 > port with a B&B electronics 485OI9TB RS-232 to RS-485 converter set with echo > jumper 'on'. > > The problem occurs more frequently with about every other packet sent at 9600 > baud, but mostly goes away at 57600 baud. This code is called from an RMI > server, but the problem is occurring with only one client present. > > I appreciate any advice/insights others have to help resolve this problem. > > --John > > PS: I did notice that there is an RS485Imp.c and associated RS485Port.java > class. I am not currently using the RS485 specific class, because I think > all I need to do with the modbus protocol is to process the echo. Since the > modbus protocol is master/slave I don't need to process collisions or tokens. > I have browsed the javadocs on the RS485Port, but so far have not modified > the code to use RS485Port. Please advize if there is a benifit in using > RS485Port with this configuration. > I would avoid RS485.java. This was a rough class to do RS485 over RS232. In theory this is possible. In practice its a disaster. You would need to look at realtime kernels before looking further. It was a bad idea :) RS232<->RS485 is best done in hardware not software. This is trivial in hardware and a nightmare in software. So just ignore those classes unless you want to play with custom kernels. -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Mon Sep 13 14:44:03 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Mon, 13 Sep 2004 16:44:03 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131253.33248.j.d.charlton@ieee.org> Message-ID: <200409131644.03769.j.d.charlton@ieee.org> Thank you. It does look like a few modifications to the app code will solve the problem without going further into rxtx. I added a sleep(100) right after sending and flushing the message. With sleep(10) I still get some packet loss. With sleep(100) all messages sent are echoed as expected: The clearInput(len, timeout) is included below. It waits for the specified number of characters (len) for the specified number of msec (timeout). It checks the input stream for the number of available characters and if less than len, sleep(100) is called to avoid spinning in the wait loop (I increased the sleep to 100 from 10 msec). If you think it may have any relavence to trying to read the input immediately after sending output, I would appreciate thoughts on the debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE --John This works: m_OutputStream.write(buf, 0, len); //PDU + CRC m_OutputStream.flush(); System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } // for RS-485 we need to read the output message before // leaving and check to see that it is the same as the one // sent. // clears out the echoed message // for RS485 if (m_Echo) { if (!clearInput(len, 500)) { System.err.println("Error: Transmit echo not received."); } } This is the debug output with DEBUG_VERBOSE defined: INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring DATA_AVAILABLE INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday public boolean clearInput(int len, int timeOut) throws ModbusIOException { boolean ret = false; try { long startTime = System.currentTimeMillis(); int numAvailable = 0; while ((numAvailable = m_InputStream.available()) < len && Math.abs(System.currentTimeMillis() - startTime) < timeOut) { // wait for message characters to be buffered try { Thread.sleep(100); } catch (InterruptedException ex) { System.err.println("InterruptedException: " + ex.getMessage()); } } if (m_InputStream.available() > 0) { m_ByteInOut.reset(); int i = 0; while (i < len && m_InputStream.available() > 0) { int ch = m_InputStream.read(); m_ByteInOut.writeByte(ch); ++i; } int dlength = m_ByteInOut.size(); if (dlength == len) { ret = true; } m_ByteIn.reset(m_InBuffer, dlength); System.out.println("Clear input: " + ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); m_ByteIn.reset(); } } catch (IOException e) { System.err.println("Error: ModbusRTUTransport::clearInput: " + e); } return ret; }//cleanInput On Monday 13 September 2004 14:24, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > I appreciate help with this and advice. I have just installed the latest > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > receive on an RS-485 network. I enabled debug and trace messages in > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > java sequence: > > > > synchronized (m_ByteOut) { > > .... code to create the message and CRC bytes... > > > > //write message > > byte[] buf = m_ByteOut.getBuffer(); > > len = m_ByteOut.size(); > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > m_ByteOut.reset(); > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > // longer interval doesn't > > help System.err.println("Error: Transmit echo not received."); } > > } > > } > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > m_ByteOut is an > > > byte array OutputStream sub class for encapsulating the byte array used > > for the modbus message. This code is in the jamod SourceForge open > > source project. > > > > These are the generated trace/debug messages: > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > received. > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > timing out prior to the 500 ms. That would be what I would investigate > first. The timings (500 ms?) are long. Can you confirm that it does > indeed work? What happens if you set the timing to something you could > measure with a watch? > > What happens if you sleep for a second and then try the clearInput()? One > thing thats different between win32 and Linux is the resolution for > timeouts in windows has another significant digit. I dont think thats the > problem here, but I do suspect there is some sort of problem with the > timeouts. > > I dont see where RXTX reports the timeout was changed. hmm. But that > could just be the amount of debugging you asked for. > > > This problem is more noticable with a slower baud rate. These messages > > were generated with 9600 baud. The problem goes away most of the time at > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > converter set with echo jumper 'on'. > > > > The problem occurs more frequently with about every other packet sent at > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > an RMI server, but the problem is occurring with only one client present. > > > > I appreciate any advice/insights others have to help resolve this > > problem. > > > > --John > > > > PS: I did notice that there is an RS485Imp.c and associated > > RS485Port.java class. I am not currently using the RS485 specific class, > > because I think all I need to do with the modbus protocol is to process > > the echo. Since the modbus protocol is master/slave I don't need to > > process collisions or tokens. I have browsed the javadocs on the > > RS485Port, but so far have not modified the code to use RS485Port. > > Please advize if there is a benifit in using RS485Port with this > > configuration. > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > In theory this is possible. In practice its a disaster. You would need > to look at realtime kernels before looking further. It was a bad idea :) > > RS232<->RS485 is best done in hardware not software. This is trivial in > hardware and a nightmare in software. So just ignore those classes unless > you want to play with custom kernels. From taj at www.linux.org.uk Mon Sep 13 16:35:09 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Mon, 13 Sep 2004 23:35:09 +0100 (BST) Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409131644.03769.j.d.charlton@ieee.org> References: <200409131253.33248.j.d.charlton@ieee.org> <200409131644.03769.j.d.charlton@ieee.org> Message-ID: On Mon, 13 Sep 2004, John Charlton wrote: > Thank you. It does look like a few modifications to the app code will solve > the problem without going further into rxtx. I added a sleep(100) right after > sending and flushing the message. With sleep(10) I still get some packet > loss. With sleep(100) all messages sent are echoed as expected: The > clearInput(len, timeout) is included below. It waits for the specified > number of characters (len) for the specified number of msec (timeout). It > checks the input stream for the number of available characters and if less > than len, sleep(100) is called to avoid spinning in the wait loop (I > increased the sleep to 100 from 10 msec). > > If you think it may have any relavence to trying to read the input immediately > after sending output, I would appreciate thoughts on the debug message: > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE This may or may not make a difference. What rxtx does when data is available is send one DATA_AVAILABLE event. Until a read is performed, rxtx will not send further DATA_AVAILABLE events - the application already knows data is available. I think if you want to play with rxtx some, you want to look at setting the timeout and threshold for the read. The sleep option is suboptimal as the data may be there. The read can wait until it gets everything. Just have a safe timeout to catch errors. public void enableReceiveThreshold( int thresh ) /* bytes */ public void enableReceiveTimeout( int time ) /* milliseconds */ > > --John > > This works: > m_OutputStream.write(buf, 0, len); //PDU + CRC > m_OutputStream.flush(); > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > > // for RS-485 we need to read the output message before > // leaving and check to see that it is the same as the one > // sent. > // clears out the echoed message > // for RS485 > if (m_Echo) { > if (!clearInput(len, 500)) { > System.err.println("Error: Transmit echo not received."); > } > } > > This is the debug output with DEBUG_VERBOSE defined: > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE It looks like the echo is already taking place, there is data available. > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > DATA_AVAILABLE > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 cf 48 It worked after multiple calls to gettimeofday. hmm. > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > public boolean clearInput(int len, int timeOut) throws ModbusIOException { > boolean ret = false; > try { > long startTime = System.currentTimeMillis(); > int numAvailable = 0; > > while ((numAvailable = m_InputStream.available()) < len && > Math.abs(System.currentTimeMillis() - startTime) < timeOut) { > // wait for message characters to be buffered > try { > Thread.sleep(100); > } catch (InterruptedException ex) { > System.err.println("InterruptedException: " + ex.getMessage()); > } > } This is not using rxtx's timeouts at all. Its also not using the DATA_AVAILABLE event. > if (m_InputStream.available() > 0) { > m_ByteInOut.reset(); > int i = 0; > while (i < len && m_InputStream.available() > 0) { > int ch = m_InputStream.read(); > m_ByteInOut.writeByte(ch); > ++i; > } Eww. grabbing one char at a time over the JNI? This is not very good. I would read a byte array and then go from there. The JNI is expensive (slow). Let the native code do that for you. > int dlength = m_ByteInOut.size(); > if (dlength == len) { > ret = true; > } > m_ByteIn.reset(m_InBuffer, dlength); > System.out.println("Clear input: " + > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > m_ByteIn.reset(); > } > } catch (IOException e) { > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > } > return ret; > }//cleanInput > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > On Mon, 13 Sep 2004, John Charlton wrote: > > > I appreciate help with this and advice. I have just installed the latest > > > rxtx-devel from cvs and am using the gnu.io.SerialPort class to transmit/ > > > receive on an RS-485 network. I enabled debug and trace messages in > > > SerialImpl.c. The RS-485 modbus RTU message is sent with the following > > > java sequence: > > > > > > synchronized (m_ByteOut) { > > > .... code to create the message and CRC bytes... > > > > > > //write message > > > byte[] buf = m_ByteOut.getBuffer(); > > > len = m_ByteOut.size(); > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > m_OutputStream.flush(); > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > m_ByteOut.reset(); > > > > > > // for RS-485 we need to read the output message before > > > // leaving and check to see that it is the same as the one > > > // sent. > > > // clears out the echoed message > > > // for RS485 > > > if (m_Echo) { > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > // longer interval doesn't > > > help System.err.println("Error: Transmit echo not received."); } > > > } > > > } > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > m_ByteOut is an > > > > > byte array OutputStream sub class for encapsulating the byte array used > > > for the modbus message. This code is in the jamod SourceForge open > > > source project. > > > > > > These are the generated trace/debug messages: > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering SerialImp.c:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:drain() > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 03 03 eb 00 01 b3 f8 > > > INFO | jvm 1 | 2004/09/13 11:12:27 | Error: Transmit echo not > > > received. > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > timing out prior to the 500 ms. That would be what I would investigate > > first. The timings (500 ms?) are long. Can you confirm that it does > > indeed work? What happens if you set the timing to something you could > > measure with a watch? > > > > What happens if you sleep for a second and then try the clearInput()? One > > thing thats different between win32 and Linux is the resolution for > > timeouts in windows has another significant digit. I dont think thats the > > problem here, but I do suspect there is some sort of problem with the > > timeouts. > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > could just be the amount of debugging you asked for. > > > > > This problem is more noticable with a slower baud rate. These messages > > > were generated with 9600 baud. The problem goes away most of the time at > > > 57600 baud. The OS is SuSE linux 9.0 with serial port /dev/ttyS0 which > > > is a RS-232 port with a B&B electronics 485OI9TB RS-232 to RS-485 > > > converter set with echo jumper 'on'. > > > > > > The problem occurs more frequently with about every other packet sent at > > > 9600 baud, but mostly goes away at 57600 baud. This code is called from > > > an RMI server, but the problem is occurring with only one client present. > > > > > > I appreciate any advice/insights others have to help resolve this > > > problem. > > > > > > --John > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > RS485Port.java class. I am not currently using the RS485 specific class, > > > because I think all I need to do with the modbus protocol is to process > > > the echo. Since the modbus protocol is master/slave I don't need to > > > process collisions or tokens. I have browsed the javadocs on the > > > RS485Port, but so far have not modified the code to use RS485Port. > > > Please advize if there is a benifit in using RS485Port with this > > > configuration. > > > > I would avoid RS485.java. This was a rough class to do RS485 over RS232. > > In theory this is possible. In practice its a disaster. You would need > > to look at realtime kernels before looking further. It was a bad idea :) > > > > RS232<->RS485 is best done in hardware not software. This is trivial in > > hardware and a nightmare in software. So just ignore those classes unless > > you want to play with custom kernels. > > _______________________________________________ > Rxtx mailing list > Rxtx at linuxgrrls.org > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx > -- Trent Jarvi taj at www.linux.org.uk From j.d.charlton at ieee.org Tue Sep 14 17:03:06 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Tue, 14 Sep 2004 19:03:06 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: References: <200409131644.03769.j.d.charlton@ieee.org> Message-ID: <200409141903.06039.j.d.charlton@ieee.org> Thanks for the help. I decided to experiment with the enableReceiveTimeout and enableReceiveThreshold as you suggested. I abandoned the enableReceiveThreshold setting though because, it causes a return to occur as soon as that number of characters is available even if you ask for more with an array read. So enableReceiveTimeout should accomplish the task of waiting for a specified number of characters with the timeout setting. I set the timeout as follows; enableReceiveTimeout(1000); /* milliseconds */ I then write a buffer to the SerialOutputStream: outputStream.write(buf, 0, len); //PDU + CRC outputStream.flush(); If i immediately try to read the SerialInputStream as follows: byte[] echoBuf = new byte[len]; int echoLen = inputStream.read(echoBuf, 0, len); it works a few times, but then fails and throws an exception. If I put the sleep(200) back in there before the read, it works everytime. So it does seem that the timeout function is not working correctly or interfering with the write operation. I set the timout to 3000 which is plenty of time and there is still no echo received if I immediatly read from the SerialInputStream after writing to the SerialOutputStream. If you have other ideas, I would appreciate your thoughts. I will reenable debugging and see if I can find out why the read times out prematurly. I will also create a simpler test to see if the problem is still present. --John On Monday 13 September 2004 18:35, Trent Jarvi wrote: > On Mon, 13 Sep 2004, John Charlton wrote: > > Thank you. It does look like a few modifications to the app code will > > solve the problem without going further into rxtx. I added a sleep(100) > > right after sending and flushing the message. With sleep(10) I still get > > some packet loss. With sleep(100) all messages sent are echoed as > > expected: The clearInput(len, timeout) is included below. It waits for > > the specified number of characters (len) for the specified number of msec > > (timeout). It checks the input stream for the number of available > > characters and if less than len, sleep(100) is called to avoid spinning > > in the wait loop (I increased the sleep to 100 from 10 msec). > > > > If you think it may have any relavence to trying to read the input > > immediately after sending output, I would appreciate thoughts on the > > debug message: INFO | jvm 1 | 2004/09/13 15:21:25 | > > report_serial_events: ignoring DATA_AVAILABLE > > This may or may not make a difference. What rxtx does when data is > available is send one DATA_AVAILABLE event. Until a read is performed, > rxtx will not send further DATA_AVAILABLE events - the application > already knows data is available. > > I think if you want to play with rxtx some, you want to look at setting > the timeout and threshold for the read. The sleep option is suboptimal as > the data may be there. The read can wait until it gets everything. Just > have a safe timeout to catch errors. > > public void enableReceiveThreshold( int thresh ) /* bytes */ > public void enableReceiveTimeout( int time ) /* milliseconds */ > > > --John > > > > This works: > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > m_OutputStream.flush(); > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > > > // for RS-485 we need to read the output message before > > // leaving and check to see that it is the same as the one > > // sent. > > // clears out the echoed message > > // for RS485 > > if (m_Echo) { > > if (!clearInput(len, 500)) { > > System.err.println("Error: Transmit echo not received."); > > } > > } > > > > This is the debug output with DEBUG_VERBOSE defined: > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | writeArray() > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:writeArray > > INFO | jvm 1 | 2004/09/13 15:21:25 | entering SerialImp.c:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | nativeDrain: trying tcdrain > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > It looks like the echo is already taking place, there is data available. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | RXTXPort:drain() returns: 0 > > INFO | jvm 1 | 2004/09/13 15:21:25 | leaving RXTXPort:drain() > > INFO | jvm 1 | 2004/09/13 15:21:25 | Sent: 58 03 00 00 00 10 cf 48 > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | report_serial_events: ignoring > > DATA_AVAILABLE > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | Clear input: 58 03 00 00 00 10 > > cf 48 > > It worked after multiple calls to gettimeofday. hmm. > > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > INFO | jvm 1 | 2004/09/13 15:21:25 | gettimeofday > > > > > > public boolean clearInput(int len, int timeOut) throws > > ModbusIOException { boolean ret = false; > > try { > > long startTime = System.currentTimeMillis(); > > int numAvailable = 0; > > > > while ((numAvailable = m_InputStream.available()) < len && > > Math.abs(System.currentTimeMillis() - startTime) < timeOut) > > { // wait for message characters to be buffered > > try { > > Thread.sleep(100); > > } catch (InterruptedException ex) { > > System.err.println("InterruptedException: " + ex.getMessage()); > > } > > } > > This is not using rxtx's timeouts at all. Its also not using the > DATA_AVAILABLE event. > > > if (m_InputStream.available() > 0) { > > m_ByteInOut.reset(); > > int i = 0; > > while (i < len && m_InputStream.available() > 0) { > > int ch = m_InputStream.read(); > > m_ByteInOut.writeByte(ch); > > ++i; > > } > > Eww. grabbing one char at a time over the JNI? This is not very good. I > would read a byte array and then go from there. The JNI is expensive > (slow). Let the native code do that for you. > > > int dlength = m_ByteInOut.size(); > > if (dlength == len) { > > ret = true; > > } > > m_ByteIn.reset(m_InBuffer, dlength); > > System.out.println("Clear input: " + > > ModbusUtil.toHex(m_ByteIn.getBuffer(), 0, dlength)); > > m_ByteIn.reset(); > > } > > } catch (IOException e) { > > System.err.println("Error: ModbusRTUTransport::clearInput: " + e); > > } > > return ret; > > }//cleanInput > > > > On Monday 13 September 2004 14:24, Trent Jarvi wrote: > > > On Mon, 13 Sep 2004, John Charlton wrote: > > > > I appreciate help with this and advice. I have just installed the > > > > latest rxtx-devel from cvs and am using the gnu.io.SerialPort class > > > > to transmit/ receive on an RS-485 network. I enabled debug and trace > > > > messages in SerialImpl.c. The RS-485 modbus RTU message is sent with > > > > the following java sequence: > > > > > > > > synchronized (m_ByteOut) { > > > > .... code to create the message and CRC bytes... > > > > > > > > //write message > > > > byte[] buf = m_ByteOut.getBuffer(); > > > > len = m_ByteOut.size(); > > > > m_OutputStream.write(buf, 0, len); //PDU + CRC > > > > m_OutputStream.flush(); > > > > System.out.println("Sent: " + ModbusUtil.toHex(buf, 0, len)); > > > > m_ByteOut.reset(); > > > > > > > > // for RS-485 we need to read the output message before > > > > // leaving and check to see that it is the same as the one > > > > // sent. > > > > // clears out the echoed message > > > > // for RS485 > > > > if (m_Echo) { > > > > if (!clearInput(len, 500)) { // 500 msec timeout interval > > > > // longer interval > > > > doesn't help System.err.println("Error: Transmit echo not > > > > received."); } } > > > > } > > > > > > > > m_OutputStream is an instance of RXTXPort.SerialOutputStream. > > > > > > m_ByteOut is an > > > > > > > byte array OutputStream sub class for encapsulating the byte array > > > > used for the modbus message. This code is in the jamod SourceForge > > > > open source project. > > > > > > > > These are the generated trace/debug messages: > > > > > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | writeArray() > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | leaving RXTXPort:writeArray > > > > INFO | jvm 1 | 2004/09/13 11:12:27 | entering > > > > SerialImp.c:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | leaving > > > > RXTXPort:drain() INFO | jvm 1 | 2004/09/13 11:12:27 | Sent: 58 > > > > 03 03 eb 00 01 b3 f8 INFO | jvm 1 | 2004/09/13 11:12:27 | Error: > > > > Transmit echo not received. > > > > > > The clearInput() is not part of rxtx so I'm wondering if maybe it is > > > timing out prior to the 500 ms. That would be what I would investigate > > > first. The timings (500 ms?) are long. Can you confirm that it does > > > indeed work? What happens if you set the timing to something you could > > > measure with a watch? > > > > > > What happens if you sleep for a second and then try the clearInput()? > > > One thing thats different between win32 and Linux is the resolution for > > > timeouts in windows has another significant digit. I dont think thats > > > the problem here, but I do suspect there is some sort of problem with > > > the timeouts. > > > > > > I dont see where RXTX reports the timeout was changed. hmm. But that > > > could just be the amount of debugging you asked for. > > > > > > > This problem is more noticable with a slower baud rate. These > > > > messages were generated with 9600 baud. The problem goes away most > > > > of the time at 57600 baud. The OS is SuSE linux 9.0 with serial port > > > > /dev/ttyS0 which is a RS-232 port with a B&B electronics 485OI9TB > > > > RS-232 to RS-485 converter set with echo jumper 'on'. > > > > > > > > The problem occurs more frequently with about every other packet sent > > > > at 9600 baud, but mostly goes away at 57600 baud. This code is > > > > called from an RMI server, but the problem is occurring with only one > > > > client present. > > > > > > > > I appreciate any advice/insights others have to help resolve this > > > > problem. > > > > > > > > --John > > > > > > > > PS: I did notice that there is an RS485Imp.c and associated > > > > RS485Port.java class. I am not currently using the RS485 specific > > > > class, because I think all I need to do with the modbus protocol is > > > > to process the echo. Since the modbus protocol is master/slave I > > > > don't need to process collisions or tokens. I have browsed the > > > > javadocs on the RS485Port, but so far have not modified the code to > > > > use RS485Port. Please advize if there is a benifit in using RS485Port > > > > with this configuration. > > > > > > I would avoid RS485.java. This was a rough class to do RS485 over > > > RS232. In theory this is possible. In practice its a disaster. You > > > would need to look at realtime kernels before looking further. It was > > > a bad idea :) > > > > > > RS232<->RS485 is best done in hardware not software. This is trivial > > > in hardware and a nightmare in software. So just ignore those classes > > > unless you want to play with custom kernels. > > > > _______________________________________________ > > Rxtx mailing list > > Rxtx at linuxgrrls.org > > http://mailman.linuxgrrls.org/mailman/listinfo/rxtx From bst_co at yahoo.com Tue Sep 14 16:51:23 2004 From: bst_co at yahoo.com (bst) Date: Tue, 14 Sep 2004 15:51:23 -0700 (PDT) Subject: [Rxtx] RXTX on AMD64 Message-ID: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Hi! I'm trying to compile RXTX on AMD64 machine and there are problems. autogen.sh doesn't create Makefile. The error messages are actually warnings, but no Makefile was created. cinclude.m4:17: warning: underquoted definition of AM_PATH_PROG_WITH_TEST run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal acinclude.m4:67: warning: underquoted definition of AM_LC_MESSAGES acinclude.m4:92: warning: underquoted definition of AM_WITH_NLS acinclude.m4:270: warning: underquoted definition of AM_GNU_GETTEXT configure script did create Makefile, but make install produces the following errors. Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Note: /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java uses unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `init_threads': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: warning: cast from pointer to integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_nativeDrain': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `read_byte_array': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: warning: cast to pointer from integer of different size /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In function `Java_gnu_io_RXTXPort_readTerminatedArray': /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In function `Java_gnu_io_LPRPort_readArray': /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function `Java_gnu_io_I2CPort_readArray': /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function `Java_gnu_io_RawPort_readArray': /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: comparison is always false due to limited range of data type /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function `Java_gnu_io_RS485Port_readArray': /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: warning: comparison is always false due to limited range of data type libtool: install: `x86_64-suse-linux/librxtxRS485.la' is not a directory Try `libtool --help --mode=install' for more information. make: *** [install] Error 1 With these warnings and errors I got .so files in x86_64-suse-linux/.libs directory, so I copied them into jre/lib/amd64 When I try to start my application I have the error: java.lang.UnsatisfiedLinkError: nativeGetVersion thrown while loading gnu.io.RXTXCommDriver Could someone tell me what did I do wrong? Thank you. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From taj at www.linux.org.uk Tue Sep 14 18:09:35 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 01:09:35 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 In-Reply-To: <20040914225123.72923.qmail@web50409.mail.yahoo.com> References: <20040914225123.72923.qmail@web50409.mail.yahoo.com> Message-ID: On Tue, 14 Sep 2004, bst wrote: > Hi! > > I'm trying to compile RXTX on AMD64 machine and there > are problems. > > autogen.sh doesn't create Makefile. The error messages > are actually warnings, but no Makefile was created. > > cinclude.m4:17: warning: underquoted definition of > AM_PATH_PROG_WITH_TEST > run info '(automake)Extending aclocal' > or see > http://sources.redhat.com/automake/automake.html#Extending%20aclocal > acinclude.m4:67: warning: underquoted definition of > AM_LC_MESSAGES > acinclude.m4:92: warning: underquoted definition of > AM_WITH_NLS > acinclude.m4:270: warning: underquoted definition of > AM_GNU_GETTEXT > > > configure script did create Makefile, but make install > produces the following errors. > > Note: /usr/local/rxtx-2.1-7pre17/./src/Configure.java > uses or overrides a deprecated API. > Note: Recompile with -Xlint:deprecation for details. > Note: > /usr/local/rxtx-2.1-7pre17/./src/CommPortIdentifier.java > uses unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `init_threads': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1213: > warning: cast from pointer to integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_nativeDrain': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:1406: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `read_byte_array': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:2790: > warning: cast to pointer from integer of different > size > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3241: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c: In > function `Java_gnu_io_RXTXPort_readTerminatedArray': > /usr/local/rxtx-2.1-7pre17/src/SerialImp.c:3297: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c: In > function `Java_gnu_io_LPRPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/ParallelImp.c:578: > warning: comparison is always false due to limited > range of data type > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c: In function > `Java_gnu_io_I2CPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/I2CImp.c:840: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RawImp.c: In function > `Java_gnu_io_RawPort_readArray': > /usr/local/rxtx-2.1-7pre17/src/RawImp.c:908: warning: > comparison is always false due to limited range of > data type > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c: In function > `Java_gnu_io_RS485Port_readArray': > /usr/local/rxtx-2.1-7pre17/src/RS485Imp.c:910: > warning: comparison is always false due to limited > range of data type > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 > > > With these warnings and errors I got .so files in > x86_64-suse-linux/.libs directory, so I copied them > into jre/lib/amd64 > > When I try to start my application I have the error: > java.lang.UnsatisfiedLinkError: nativeGetVersion > thrown while loading gnu.io.RXTXCommDriver > > > Could someone tell me what did I do wrong? > It should not be required to run autogen.sh. I've got an example of running configure and build fresh from the tar on an opteron redhat fedora-devel system here: http://www.qbang.org/typescript The libtool failing with: > libtool: install: `x86_64-suse-linux/librxtxRS485.la' > is not a directory > Try `libtool --help --mode=install' for more > information. > make: *** [install] Error 1 Is bothersome. I'm not sure what is different. After autogen.sh with whatever versions of auto'break' are on your system, anything is possible :) But A couple things, what does nm say? # nm librxtxSerial.so |grep nativeGetVersion 0000000000005120 T Java_gnu_io_RXTXCommDriver_nativeGetVersion What does file say? librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Finally, what does java say? Is it 64 bit? If not you will need to change the --target option to configure to match a 32bit jvm. ../configure --target=i386-suse-linux /usr/local/j2sdk1.4.2/bin/java -version java version "1.4.2-rc1" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-rc1) Java HotSpot(TM) 64-Bit Server VM (build Blackdown-1.4.2-rc1, mixed mode) -- Trent Jarvi taj at www.linux.org.uk From pashmina.mukhi at patni.com Tue Sep 14 22:32:40 2004 From: pashmina.mukhi at patni.com (Pashmina Mukhi) Date: Wed, 15 Sep 2004 10:02:40 +0530 Subject: [Rxtx] RxTx to detect free ports on system Message-ID: <003a01c49add$098d6d90$036ad103@patni.com> Hi, I am using Rxtx API, for an application which uses dials-up to some devices and retrieves their data. To find the available modems/ports on the Linux box, am using the following: //this method checks if port/modem is free. if yes return portID else return null //calling class will check null, and take appropriate action. public static CommPortIdentifier checkModem(){ CommPortIdentifier ID = null; Enumeration ports = CommPortIdentifier.getPortIdentifiers(); try{ while(ports.hasMoreElements()){ ID = (CommPortIdentifier) ports.nextElement(); if (ID.getPortType() == CommPortIdentifier.PORT_SERIAL && !ID.isCurrentlyOwned()){ Log.put("The port " + ID.getName() +" is free"); return(ID); } } }catch(Exception e) { Log.put("Error occured in Modem bank."); } return null;//This Returns Null } Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... Thanks & Regards, Pashmina Mukhi ------------------------------------------------------------------------------------------------------------------------ Disclaimer: This e-mail message along with attachment, contain Patni GE Confidential, proprietary & legally privileged information for the sole use of the person or entity to whom this message was originally addressed. Any review, e-transmission dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this e-mail in error kindly delete this e-mail from your records. If it appears that this mail has been forwarded to you without proper authority, please notify the sender and delete this mail. This email (in whole or in part) is not to be reproduced or furnished to third parties or made public without the prior express written permission of the sender. ------------------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/a1d7ef39/attachment-0033.html From taj at www.linux.org.uk Wed Sep 15 07:13:11 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 14:13:11 +0100 (BST) Subject: [Rxtx] RxTx to detect free ports on system In-Reply-To: <003a01c49add$098d6d90$036ad103@patni.com> References: <003a01c49add$098d6d90$036ad103@patni.com> Message-ID: >> Using this I am only able to detect the 1st four modems/ports on the Linux system (ttyG0_00 to ttyG0_03). Four new modems are connected to the system, but using the above code, we cannot detect them. Could this be a problem with configururation of the modems or something else? If i use "wvdial" and dial on port 04, it does so successfully.... ??? -- rxtx does not have the capability to rescan ports currently. It scans once at startup. So I suspect the application needs to be restarted. If the modems are ttyG0_0[4567], they should be found then. If you are able to open the port with wvdial, rxtx will open the port during enumeration when it starts up and register it as available. Rescanning the ports is a feature that is requested every few months but has not been interesting enough for anyone to implement. If the ports are a different type, RXTXCommDriver may need to be modified to look for the ports. -- Trent Jarvi taj at www.linux.org.uk From taj at www.linux.org.uk Wed Sep 15 09:12:26 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Wed, 15 Sep 2004 16:12:26 +0100 (BST) Subject: [Rxtx] RXTX on AMD64 (fwd) Message-ID: the mail-list fell off the cc list. -- Trent Jarvi taj at www.linux.org.uk ---------- Forwarded message ---------- Date: Wed, 15 Sep 2004 07:54:26 -0700 (PDT) From: bst To: taj at www.linux.org.uk Subject: [Rxtx] RXTX on AMD64 Hi Trent, Thank you for the prompt response. nm librxtxSerial.so |grep nativeGetVersion returns nothing. # nm librxtxSerial-2.1-7pre17.so 0000000000100a68 A __bss_start 0000000000000750 t call_gmon_start 0000000000100a68 b completed.1 0000000000100a08 d __CTOR_END__ 0000000000100a00 d __CTOR_LIST__ w __cxa_finalize@@GLIBC_2.2.5 0000000000000800 t __do_global_ctors_aux 0000000000000770 t __do_global_dtors_aux 0000000000100848 d __dso_handle 0000000000100a18 d __DTOR_END__ 0000000000100a10 d __DTOR_LIST__ 0000000000100860 A _DYNAMIC 0000000000100a68 A _edata 0000000000100a70 A _end 0000000000000838 T _fini 00000000000007d0 t frame_dummy 0000000000100858 r __FRAME_END__ 0000000000100a28 A _GLOBAL_OFFSET_TABLE_ w __gmon_start__ 0000000000000708 T _init 0000000000100a20 d __JCR_END__ 0000000000100a20 d __JCR_LIST__ w _Jv_RegisterClasses 0000000000100850 d p.0 The file says librxtxSerial-2.1-7pre17.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped # $JAVA_HOME/jre/bin/java -version java version "1.5.0-rc" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-rc-b63) Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-rc-b63, mixed mode) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From j.d.charlton at ieee.org Wed Sep 15 09:50:26 2004 From: j.d.charlton at ieee.org (John Charlton) Date: Wed, 15 Sep 2004 11:50:26 -0400 Subject: [Rxtx] RS-485 echo processing In-Reply-To: <200409141903.06039.j.d.charlton@ieee.org> References: <200409141903.06039.j.d.charlton@ieee.org> Message-ID: <200409151150.26175.j.d.charlton@ieee.org> Trent and all: I did some more experimenting with enableReceiveThreshold() and enableReceiveTimeout() and have a combination that works now to consistently read the RS-485 echo without missing transmitted packets. Just setting enableReceiveTimeout() alone does not seem to work because the read(buf, 0, len) returns before the timeout set in enableReceiveTimeout(). I tried various timeout settings up to 10000 ms and read(buf, 0, len) still returns prematurely before timeout is reached and before len characters are received. The code in the attached tgz file works consistently. If I use both enableReceiveThreshold(len) and enableReceiveTimout(500), no packets are lost. With a bit more testing, I am able to pickup the echo with timeout setting down to enableReceiveTimeout(10). It does timeout with enableReceiveTimeout(1) which in encouraging since I am transmitting at 9600 baud for this test and it should timeout at 1msec. Thanks for the help, --John -------------- next part -------------- A non-text attachment was scrubbed... Name: echotest.tgz Type: application/x-tgz Size: 1721 bytes Desc: not available Url : http://mailman.qbang.org/pipermail/rxtx/attachments/20040915/d5081611/attachment-0001.bin From p_edson at yahoo.com Thu Sep 16 09:46:27 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Thu, 16 Sep 2004 08:46:27 -0700 (PDT) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY Message-ID: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Hi, With both pre16 and pre17 I am seeing different behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY events between win and linux under jvm 1.4.x. On windows, I get one such event when I finish an asynchronous write. On linux, I am getting pounded with them as soon as I open the port, even before I send any data, and they just keep going before during and after sending data. I have tried to isolate the difference, but haven't had any luck. With pre16 using JVM 1.3 this doesn't seem to be the case - linux behaves the same as windows. Has anyone encountered this, or have any ideas? Thanks. _______________________________ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com From taj at www.linux.org.uk Thu Sep 16 10:48:23 2004 From: taj at www.linux.org.uk (Trent Jarvi) Date: Thu, 16 Sep 2004 17:48:23 +0100 (BST) Subject: [Rxtx] SerialPortEvent.OUTPUT_BUFFER_EMPTY In-Reply-To: <20040916154627.66365.qmail@web12703.mail.yahoo.com> References: <20040916154627.66365.qmail@web12703.mail.yahoo.com> Message-ID: On Thu, 16 Sep 2004, Patrick Edson wrote: > Hi, > > With both pre16 and pre17 I am seeing different > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > events between win and linux under jvm 1.4.x. > > On windows, I get one such event when I finish an > asynchronous write. On linux, I am getting pounded > with them as soon as I open the port, even before I > send any data, and they just keep going before during > and after sending data. I have tried to isolate the > difference, but haven't had any luck. > > With pre16 using JVM 1.3 this doesn't seem to be the > case - linux behaves the same as windows. > > Has anyone encountered this, or have any ideas? > > Thanks. > > > In SerialImp.c, look for code like: send_event( eis, SPE_DATA_AVAILABLE, 1 ) And modify it to: if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) { eis->eventflags[SPE_DATA_AVAILABLE] = 0; } There are two. Only one is used depending upon the port. Some ports are less complete than others so there is two code paths for data available. I suspect someone was reporting problems with not recieving enough data available events. The lower API on linux is going to be constantly noting that there is data available until it is read. You can shut down the data available event sending as above as above. The flags should trigger back after a successfull read. While data is available, select will not block. It may be possible to do something more sane with poll(). The result is sleep() is used to slow down the eventLoop. You dont want to leave data on the port. If you notice CPU use, look for the data_available logic and increase the sleeps or look at a poll() implementation. -- Trent Jarvi taj at www.linux.org.uk From p_edson at yahoo.com Fri Sep 17 08:51:18 2004 From: p_edson at yahoo.com (Patrick Edson) Date: Fri, 17 Sep 2004 07:51:18 -0700 (PDT) Subject: [Rxtx] (no subject) In-Reply-To: <20040917110002.1841E732F7@mail.linuxgrrls.org> Message-ID: <20040917145118.27375.qmail@web12704.mail.yahoo.com> > Content-Type: TEXT/PLAIN; charset=US-ASCII > > On Thu, 16 Sep 2004, Patrick Edson wrote: > > > Hi, > > > > With both pre16 and pre17 I am seeing different > > behavior for SerialPortEvent.OUTPUT_BUFFER_EMPTY > > events between win and linux under jvm 1.4.x. > > > > On windows, I get one such event when I finish an > > asynchronous write. On linux, I am getting > pounded > > with them as soon as I open the port, even before > I > > send any data, and they just keep going before > during > > and after sending data. I have tried to isolate > the > > difference, but haven't had any luck. > > > > With pre16 using JVM 1.3 this doesn't seem to be > the > > case - linux behaves the same as windows. > > > > Has anyone encountered this, or have any ideas? > > > > Thanks. > > > > > > > > In SerialImp.c, look for code like: > > send_event( eis, SPE_DATA_AVAILABLE, 1 ) > > And modify it to: > > if(!send_event( eis, SPE_DATA_AVAILABLE, 1 )) > { > eis->eventflags[SPE_DATA_AVAILABLE] = 0; > } > > There are two. Only one is used depending upon the > port. Some ports are > less complete than others so there is two code paths > for data available. > > I suspect someone was reporting problems with not > recieving enough data > available events. The lower API on linux is going > to be constantly noting > that there is data available until it is read. You > can shut down the > data available event sending as above as above. The > flags should trigger > back after a successfull read. While data is > available, select will not > block. It may be possible to do something more sane > with poll(). The > result is sleep() is used to slow down the > eventLoop. You dont want to > leave data on the port. If you notice CPU use, look > for the > data_available logic and increase the sleeps or look > at a poll() > implementation. > Thanks, Trent, I'll try this. __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From Mel.Bartels at weyerhaeuser.com Mon Sep 20 17:23:51 2004 From: Mel.Bartels at weyerhaeuser.com (Bartels, Mel) Date: Mon, 20 Sep 2004 16:23:51 -0700 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: <1C153DD623208B4AB8D01006A82749310B11C7@wawtcixm16.corp.weyer.pri> Hello. I have a successful application in Java using RXTX. Without any code changes, users are able to communicate via the serial/USB ports whether Windows, Mac, or Linux platforms, thanks to RXTX. Now, I am investigating porting a subset of the application to handhelds. After some research, I am not clear on the best approach(es). I'd like to keep as much of my code unchanged as possible, including calls to RXTX. I see that RXTX works under WinCE, but how about simpler(?) implements such as Java on Palm OS? Any comments would be appreciated, to help me get going in a good direction. Mel Bartels From Michal_Hobot at drq.pl Tue Sep 21 06:32:45 2004 From: Michal_Hobot at drq.pl (Michal_Hobot at drq.pl) Date: Tue, 21 Sep 2004 14:32:45 +0200 Subject: [Rxtx] RXTX and handhelds - looking for starting recommendations Message-ID: JVMs for mobile devices quite often have javax.comm library included. I.e. CrEME have one, VM for Symbian also have one. I don't know separate comm package for PalmOS. One of the problems is - PalmOS doesn't have filesystem at all. So adding something to classpath is hard. Cheers, Michal -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mailman.qbang.org/pipermail/rxtx/attachments/20040921/f13ea11a/attachment-0033.html From dmarkman at mac.com Wed Sep 22 21:33:07 2004 From: dmarkman at mac.com (Dmitry Markman) Date: Wed, 22 Sep 2004 23:33:07 -0400 Subject: [Rxtx] Re: Installer for javax.comm on Mac OS X In-Reply-To: References: Message-ID: <4902EF99-0D11-11D9-A750-000A95DA5E9C@mac.com> maybe somebody remembers how that happened that lock directory for Apple was changed to the /var/lock ? (only in 2.0.X distribution) #if defined(__APPLE__) # define DEVICEDIR "/dev/" /*# define LOCKDIR "/var/spool/uucp"*/ # define LOCKDIR "/var/lock" # define LOCKFILEPREFIX "LK." # define UUCP that's why librxtxSerial.jnilib, that installed by my installer doesn't work maybe there is a reason to change LOCKDIR from /var/spool/uucp to the /var/lock? if there is a serious reason then I'll change my installer too: if [ ! -d /var/lock ] then sudo mkdir /var/lock fi sudo chgrp uucp /var/lock sudo chmod 775 /var/lock if [ ! `sudo niutil -readprop / /groups/uucp users | grep $curruser > /dev/null` ] then sudo niutil -mergeprop / /groups/uucp users $curruser fi but that doesn't look good to me Dmitry Markman From jwo at soi.city.ac.uk Thu Sep 23 02:24:16 2004 From: jwo at soi.city.ac.uk (Jo Wood) Date: Thu, 23 Sep 2004 09:24:16 +0100 (BST) Subject: [Rxtx] Are latest MacOSX binaries available? Message-ID: I have been sucessfully using RXTX 2.1-7pre17 for a while now on my windows and Linux platform without problems. I have been distributing the binararies with my software that connects to GPS via the serial port (http://www.landserf.org) for Windows, Linux and MacOSX platforms. The problem I have is with the