Serial Port Echo Disabling

Is there a way to turn off an echo on the serial port?
I am sending some commands to the serial and they get echoed back before I can read a reply. Sending the same commands via Socket doesn't give me an echo, so my algorithm for Serial and TCP/IP connection has to differ. It would be nice, however, to just turn off the echo.
Any ideas?
Thanks!
Janny.

I am not connecting through a modem but doing a direct serial connection from PC to a telecom equipment serial port. IF I disable an echo using ATE modem command the equipment I sent the commands to freaks out since it can't recognize the command.

Similar Messages

P35 Neo Combo won't boot with Serial Port disabled

Need to disable onboard serial to free up Com1 for new PCI Serial card. Older DNC program needs to use COM1. As soon as the onboard Serial Port is disabled the PC won't boot. Have updated BIOS to latest version. Have seen a couple other people mention this on the net but no solutions yet. Any ideas?

Probably a BIOS bug.
Try contact MSI for on this issue and see if they could provide any fix.
>>How to contact MSI.<<

Disable/enable the serial port

Hello All,
I am using Labview to communicate with a Microchip PIC virtual serial port. Ocassionally the serial comms is lost. To recover the connection I open Device Manager then right click the faulty comm port then select disable ( a red cross appears on the icon). Next right click the port again and select enable. The port now communicates correctly again.
Is there a way to use System Exec to drive this behavior automatically once a fault occurs or some other method to drive DM using methods and properties?
Many Thanks
Chris
Solved!
Go to Solution.

Thanks for that, I am surprised at how simple it is to use DevCon however I still dont understand why cant I detect when the serial port fails.
Excellent workaround though

Serial port configuration on PXI 8185 w/ 8423 card.

I'm trying to configure wire mode for the serial ports on a 8423 RS485 card with the NI-RT.INI file, but it changes the RS232 ports on the controler. The Property node method doesn't work at all. Using LV-RT 7.1 and loading from mac OSX.

I just figured it out. I was trying to set the wire mode on the RS485 to two-wire auto, and the RS232 to RS232-auto. The problem was that I had a 'WIRE_MODE=xxx' in my NI-RT.INI file, this disabled the ability to set the wire modes with the serial property node. In addition, the documentation has changed: The pre-VISA 3 instructions were to let (page 6-5 NI Serial Hardware and Software for Windows User Manual)
RS485 4wire WIRE_MODE=128
RS485 2wire DTR w/echo =129
RS485 2wire DTR cont =130
RS485 2wire auto =131
but the new VISA serial has these as 0,1,2,3 respectively, with 128, 129 and 130 being RS232 wire modes. 131 is undefined now.
So it is all working as of this afternoon. Was obtuse to find these errors though, and neither the NI-RT.INI file
or the new VISA wire mode setting ability are documented correctly anywhere that I could find. Thanks for the offer of help!

Java ME 8 Permission check failed when opening a serial port

I have a larger Jave ME8.1 application that was going well until I tried to add one last piece, reading and writing data from a serial port. This was left to last because it is trivial, at least in most programming languages. The is IDE NetBeans 8.0.2 running on a Windows 7 PC. The platform is a Raspberry Pi B or B+ (I have tried both) with the most current Raspbian (12/24/2014 I believe). To simplify the process I created a new app with just the open and close code and this generates the same error I am experiencing in the larger application. The program is as follows:
package javamecomapp;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.microedition.io.CommConnection;
import javax.microedition.io.Connector;
import javax.microedition.midlet.MIDlet;
* @author ****
public class JavaMEcomApp extends MIDlet {
    static int BAUD_RATE = 38400;
    static String SERIAL_DEVICE = "ttyAMA0";
    static CommConnection commConnection = null;
    static OutputStream os = null;
    static InputStream is = null;
    static String connectorString;
    private int rtnValue = -1;
    @Override
    public void startApp() {
        java.lang.System.out.println("Opening comm port.");
        try {
            rtnValue = JavaMEcomApp.openComm();
        } catch (IOException ex) {
            Logger.getLogger(JavaMEcomApp.class.getName()).log(Level.SEVERE, null, ex);
    @Override
    public void destroyApp(boolean unconditional) {
        java.lang.System.out.println("Closing comm port.");
        try {
            rtnValue = JavaMEcomApp.closeComm();
        } catch (IOException ex) {
            Logger.getLogger(JavaMEcomApp.class.getName()).log(Level.SEVERE, null, ex);
        private static int openComm()throws IOException {
            java.lang.System.out.println("Opening comm port.");
            connectorString = "comm:" + SERIAL_DEVICE + ";baudrate=" + BAUD_RATE;
            commConnection = (CommConnection)Connector.open(connectorString);
            is = commConnection.openInputStream();
            os = commConnection.openOutputStream();
        return 0;
    private static int closeComm()throws IOException {
        java.lang.System.out.println("Closing comm port.");
            is.close();
            os.close();
            commConnection.close();
        return 0;
If I comment out the JavaMEcomApp.openComm and closeComm lines it runs fine. When they are included, the following error is dumped to the Raspberry Pi terminal:
Opening comm port.
Opening comm port.
[CRITICAL] [SECURITY] iso=2:Permission check failed: javax.microedition.io.CommProtocolPermission "comm:ttyAMA0;baudrate=38400" ""
TRACE: <at java.security.AccessControlException: >, startApp threw an Exception
java.security.AccessControlException:
- com/oracle/meep/security/AccessControllerInternal.checkPermission(), bci=118
- java/security/AccessController.checkPermission(), bci=1
- com/sun/midp/io/j2me/comm/Protocol.checkForPermission(), bci=16
- com/sun/midp/io/j2me/comm/Protocol.openPrim(), bci=31
- javax/microedition/io/Connector.open(), bci=77
- javax/microedition/io/Connector.open(), bci=6
- javax/microedition/io/Connector.open(), bci=3
- javamecomapp/JavaMEcomApp.openComm(), bci=46
- javamecomapp/JavaMEcomApp.startApp(), bci=9
- javax/microedition/midlet/MIDletTunnelImpl.callStartApp(), bci=1
- com/sun/midp/midlet/MIDletPeer.startApp(), bci=5
- com/sun/midp/midlet/MIDletStateHandler.startSuite(), bci=246
- com/sun/midp/main/AbstractMIDletSuiteLoader.startSuite(), bci=38
- com/sun/midp/main/CldcMIDletSuiteLoader.startSuite(), bci=5
- com/sun/midp/main/AbstractMIDletSuiteLoader.runMIDletSuite(), bci=130
- com/sun/midp/main/AppIsolateMIDletSuiteLoader.main(), bci=26
java.security.AccessControlException:
- com/oracle/meep/security/AccessControllerInternal.checkPermission(), bci=118
- java/security/AccessController.checkPermission(), bci=1
- com/sun/midp/io/j2me/comm/Protocol.checkForPermission(), bci=16
- com/sun/midp/io/j2me/comm/Protocol.openPrim(), bci=31
- javax/microedition/io/Connector.open(), bci=77
- javax/microedition/io/Connector.open(), bci=6
- javax/microedition/io/Connector.open(), bci=3
- javamecomapp/JavaMEcomApp.openComm(), bci=46
- javamecomapp/JavaMEcomApp.startApp(), bci=9
- javax/microedition/midlet/MIDletTunnelImpl.callStartApp(), bci=1
- com/sun/midp/midlet/MIDletPeer.startApp(), bci=5
- com/sun/midp/midlet/MIDletStateHandler.startSuite(), bci=246
- com/sun/midp/main/AbstractMIDletSuiteLoader.startSuite(), bci=38
- com/sun/midp/main/CldcMIDletSuiteLoader.startSuite(), bci=5
- com/sun/midp/main/AbstractMIDletSuiteLoader.runMIDletSuite(), bci=130
- com/sun/midp/main/AppIsolateMIDletSuiteLoader.main(), bci=26
Closing comm port.
Closing comm port.
TRACE: <at java.lang.NullPointerException>, destroyApp threw an Exception
java.lang.NullPointerException
- javamecomapp/JavaMEcomApp.closeComm(), bci=11
- javamecomapp/JavaMEcomApp.destroyApp(), bci=9
- javax/microedition/midlet/MIDletTunnelImpl.callDestroyApp(), bci=2
- com/sun/midp/midlet/MIDletPeer.destroyApp(), bci=6
- com/sun/midp/midlet/MIDletStateHandler.startSuite(), bci=376
- com/sun/midp/main/AbstractMIDletSuiteLoader.startSuite(), bci=38
- com/sun/midp/main/CldcMIDletSuiteLoader.startSuite(), bci=5
- com/sun/midp/main/AbstractMIDletSuiteLoader.runMIDletSuite(), bci=130
- com/sun/midp/main/AppIsolateMIDletSuiteLoader.main(), bci=26
java.lang.NullPointerException
- javamecomapp/JavaMEcomApp.closeComm(), bci=11
- javamecomapp/JavaMEcomApp.destroyApp(), bci=9
- javax/microedition/midlet/MIDletTunnelImpl.callDestroyApp(), bci=2
- com/sun/midp/midlet/MIDletPeer.destroyApp(), bci=6
- com/sun/midp/midlet/MIDletStateHandler.startSuite(), bci=376
- com/sun/midp/main/AbstractMIDletSuiteLoader.startSuite(), bci=38
- com/sun/midp/main/CldcMIDletSuiteLoader.startSuite(), bci=5
- com/sun/midp/main/AbstractMIDletSuiteLoader.runMIDletSuite(), bci=130
com/sun/midp/main/AppIsolateMIDletSuiteLoader.main(), bci=26
I have tried this with three different serial ports, /dev/ttyAMA0 (yes I did disable the OS from using it), an arduino board /dev/ttyACM0, and a USB to RS485 adaptor /dev/ttyUSB0. All of these ports could be connected and use normally with both a C program and terminal program in the Pi. The API Permissions were set in the project properties / Application Descriptor / API Permissions to jdk.dio.DeviceMgmtPermission "/dev/ttyAMA0". This of course was changed as I tested different devices.
I found a reference suggesting adding the line "authentication.provider = com.oracle.meep.security.NullAuthenticationProvider" to the end of the jwc_properties.ini file. This had no effect. I found references that during development in eclipse and NetBeans, the app is already elevated to the top level so this should not be an issue until deployment. This does not appear to be the case.
I am out of time and need a solution quickly. Any suggestions are welcome.

Terrence,
   Thank you for responding and confirming the issues I'm having with static addressing. As far as the example above, I do have the standard LEDs working correctly, however, the example I'm referring to above is from the JavaME samples using the GPIO Port for the LEDS, according to the Device I/O Preconfigured List you referenced:
GPIO Ports
The following GPIO ports are preconfigured.
Devicel ID
Device Name
Mapped
Configuration
8
LEDS
PTB22
PTE26
PTB21
direction = 1 (Output only)
initValue = 0
GPIOPins:
controllerNumber = 1
pinNumber = 22
mode = 4 (Push-pull mode)
controllerNumber = 4
pinNumber = 26
mode = 4 (Push-pull mode)
controllerNumber = 1
pinNumber = 21
mode = 4 (Push-pull mode)
So is the assumption that using GPIOPort for accessing the GPIO port for Device ID 8 as listed in the Device I/O Preconfigured list not supported?

Reading/writing to serial port w/ VISA in Labview

I'm writing a Labview program to control and to read data from a Varian vacuum pump controller. It is connected to the serial port in my computer, and I have been trying to open a VISA session to communicate with the instrument. So far, however, the computer cannot see the instrument--I get the same error messages reading and writing to the instrument as I do to an empty serial port. Does anyone have any suggestions on what the problem might be? Thank you.

There are a lot of possiblities. Is the cable correct? You probably need a crossover cable (TX and RX) swapped. You also need to check and make sure the serial ports on both ends are set the same (i.e. baud rate, handshaking, stop bits, etc.). Make sure that the port is enabled. I've seen people try to use a comm port only to find that a modem card installation caused the port to be disabled. You could also try using hyperterminal to talk to the instrument. If you can communicate there, you can eliminate any hardware problem.

After writing into serial port, the same message gets bounced back into the Inqueue also. If anyone know how to avoid this, please rpely.

Hi,
After writing into serial port, the same message gets bounced back into the Inqueue also. If anyone know how to avoid this, please reply.
Thanks,
Ganesh

If you disconnect the cable going to the serial device, do you still get the echo? If so you have something going on in the port setup. If disconnecting the cable stops the echo then the device you're talking to is doing it - which would be my bet. One thing to check is whether this might not be normal operation. I have seen devices that if a command was successful, it simply echo'd back the command string you had sent. Also many serial devices have setting for specifying whether they are to echo commands.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps

Serial port: Input/output signal errantly combined

I am currently in the process of using LabView to replace another user interface for a scientific instrument.
LabView is connected to this instrument through a serial port. The instrument streams 25 bytes of binary data every second to the computer. I can read the binary string (VISA Read) and save contiuously to disk using a while loop. In addition, there are a few instructions I can send to the instrument that will do various functions (start logging, turn LEDs on/off, etc). I can successfully send these instructions to the instrument using the previous interface, and in a stand-alone vi using VISA Write, but when I place the VISA Write function into the larger interface vi, signals go haywire. Specifically, there are two separate LEDs that I can toggle with two different commands, but when in the larger interface vi, both commands toggle the same LED. Also, it appears that the singal I send to the instrument (a single ASCII character) immediately bounces back to the computer into the 25 bytes of streaming binary data. In other words, after I press the LED "on" key, one column of my streaming data changes when it is not supposed to (ex: after Binary to ASCII conversion, it changes from a single digit to a twenty digit value).
Initially, I thought the problem was the sequence of VISA Read/Write. In the current configuration, I read all data, then allow for Write commands. Both the VISA functions are within the same While loop to continuously monitor the data. Is it possible the Write signal output is not leaving the while loop and being read as input? What would make the instrument read two different commands as the same one? My goal is to run an interface that displays the streaming data as ASCII, and allows for a few different toggle options while the interface is running - is there are more efficient/elegant way than a while loop?
~Going Bananas
Solved!
Go to Solution.

New replies now in gray.
CodeMunkee wrote:
1. If you keep giving me good advice like this, I'll be tempted to change the background to Baltimore prison purple.
I'll ignore this statement.
2. The buffer now lives outside the loop. I understand clearly. Part of the problem might be my instrument - when I cycle power the 19 digit number that was 'echoed' disappears. Forget about that display stuff, it works properly - I accidentally removed the time delay when editing the vi. But you do bring up an interesting point...
Without the delay, the loop ran much faster. If the bytes weren't at the port, the read statement would have returned nothing when it read zero bytes, thus blanking out the indicator rather quickly.
Yes, Hexadecimal display shows 04 to indicate the end of the 25-byte data sample.
Doing a bytes at port read is not always a good idea. If not all the bytes had arrived yet when you ask for the read, you won't get all the data. The remaining data being sent in that stream from the instrument will show up at the front of the buffer on the next read command.
While this isn't a common occurence, it does happen. How can I prevent this from ever happening?
Since you know each commands ends with a hex 04 (ASCII character for EOT), you could enable the termination character when you configure the serial port. Set the termination character to be 4. Then when you execute the VISA read, read a large number of bytes such as 25 or more. The read will terminate at either the timeout, the requested number of bytes, or when the termination character is read. With this setup, you could eliminate the wait statement and also not request the number of bytes as the port. The VISA read will control the pacing of the loop. Any extra bytes after the termination character are part of the next frame of data and will wait around until the next time you read the VISA port.
3. Implementing your ideas for the latch button works better. I am still encountering issues with these commands however. Attached is the new vi. There are two commands I want to send, 't' turns on the LED light (they blink for 30 sec then time out), and the latch works perfectly for that, 'p' turns on the magnetometer light (an additional 'p' is required to turn it off), but I cannot get the command sent to the mag while the loop is running. It turns on either at the beginning of the vi, or at the end of the vi (after Finish button is pressed). This leads me to think the command 'p' is stuck inside the loop. I tried adding another film strip (see attached vi) for the toggles to force the issue, but it didn't work. Additionally, the 'p' command effectively works as a 't' command, and the LED lights begin to blink when I press the 'p' button. This isn't supposed to happen, and leads me to believe the 'p' command does in fact exit the loop but in the wrong manner.
The "film strip" is another frame of a flat sequence structure. It enforces the order of execution. The next frame can't execute until everything in the prior frame has completed. It isn't necessary in your case because the Error and VISA wires determine the order of execution with respect to the other VISA statements. But it shouldn't hurt.
There is no reason the "p" case structure should behave any differently than the "t" case structure. Although you should wire the error wire through in the False case of the "p" structure like you did for the "t" structure. There is no "exiting of the loop" in either case. The loop runs until the stop button is pressed. I would check the manual to see that t and p commands do what you think they should do. Do they need a termination character of their own when they are sent? Should they be upper case letters rather than lower case? You can run NI Spy on your serial port and see the operations occurring with it and see the data coming in and what data is going out. I would be suspicious that the device is not handling the command properly.
Any ideas? I think I've tried to put the toggle buttons outside the loop before, but then could only toggle once before the loop took over. Ideally, these toggles would be available at any time while the data is streaming, so therefore inside the loop?
The toggle buttons need to be within the loop so that they can be read on every iteration of the loop. Outside the loop, as you discovered, they are only read once at the very beginning before the loop is started.
4. Thank you for the suggestion about the Selection Mode for the Open/Create File option. It is annoying to create a file first. I made the change, but I still get error messages when I use a file that does not yet exist. LabView takes me to the first Open/Create/Replace vi when the error occurs. Is there something else I must do?
On the open file VI, there is an input that is Open as default when unwired. Create a constant there and change to Replace or Create.
Remember, if you have any questions about the way LabVIEW is handling something with serial ports, close the port within LabVIEW. Open Hyperterminal and try the commands from there.
Message Edited by Ravens Fan on 01-13-2009 03:55 PM

Bytes at serial port returns allways zero value

hello, in my code don't works Bytes At Port as I'm expexting. Program receieves data normally, but Bytes At Port return allways zero.
2nd problem: It is possible to use VISA Read in both of parallel loops ? Purpose of my first loop is sending commads and I want to evaluate synchronous answers imediatly in this loop. Second loop receieves and evaluates asynchronous data flowing from the measurement device when measurement is acitivated.
Thanks.

You're sort of answering your first question with your second question. In the first loop the Bytes at Port is meaningless, unless you are intending to use it to perform a read in there. However, since you're reading in the second loop (incorrectly, by the way - more on that later), then there's nothing in the buffer, so you'll get zero.
You can read in as many places as you want. Whether or not it makes sense to do is a different story. It depends on how the data is coming over the serial port. If the instrument you're talking to is sending data continuously, but "sneaks" in a response to a command between two messages, then you obviously don't want to be reading the response to the command in your second loop. The serial port is just one pipe. It's up to you to determine where the data belongs. Furthermore, you can't be guaranteed of getting all of the bytes at once, which means you might read, say, part of the "asynchronous" message, then get the rest in the next iteration as well as the responsed to a command you sent. As far as the Bytes At Port is concerned, it just sees a bunch of bytes. It doesn't know that, for example, the first 2 are the remainder of the asynchronous message, and the rest are the response to the command. Does the instrument not have something in the communication protocol to allow you to distinguish?
As promised, the way you're doing the read: You are setting up the configure VI to disable the termination character, yet you are wiring a termination character. Which is it? Do you want the read to stop at the termination character, or not? If you don't use a termination character, then you need to use Bytes At Port so you know how many bytes to read. You have that property node in the second loop, but you are not using it. Instead you are wiring a constant of 1000 to the VISA Read. This will only work if you have termination enabled. But you don't. See the problem?

PCI Serial Port error

the computer says it is disabled, and when i try to reinstall or fix the problem through the options, nothing works. what do i do?

Is this WIndows 7? There is something about the Intel security drivers and WIndows 7 that crates problem virtual serial ports. I just remember seeing something about it.
T61p, T400
formerly x23, x40

Cisco Router 2600 Serial Port communications

I am working on configuring communications Router to Router through serial port. I have seen some videos and read some documentations. My configuration is as follows:
R1 (DCE) -> f0/0 192.168.1.1/24 - s0/0 192.168.2.1/24 <-----> Router2 ->(DTE) S0/1 192.168.2.2/24 f0/0 192.168.3.1.
I have configured the routing tables at both routers. It works when I ping from router to router and router to hosts successfully. Nevertheless, I can ping from hosts to the default gateways, but I cannot ping from hosts to the serial ports (adjacency). In short I cannot communicate from Network1 to Network2. Please do I have to do any extra configuration.

Router 1 (KelliR)
KelliR#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 192.168.1.1 YES manual up up
Serial0/0 192.168.3.1 YES manual up up
TokenRing0/0 unassigned YES unset administratively down down
Serial0/1 unassigned YES unset administratively down down
KelliR#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
C 192.168.1.0/24 is directly connected, Ethernet0/0
S 192.168.2.0/24 [1/0] via 192.168.3.2
C 192.168.3.0/24 is directly connected, Serial0/0
============================================
Router 2 (HelderR)
HelderR#
HelderR#show ip interface brief
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 192.168.2.1 YES manual up up
Serial0/0 192.168.3.2 YES SLARP up up
TokenRing0/0 unassigned YES unset administratively down down
Serial0/1 unassigned YES unset administratively down down
HelderR#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
S 192.168.1.0/24 [1/0] via 192.168.3.1
C 192.168.2.0/24 is directly connected, Ethernet0/0
C 192.168.3.0/24 is directly connected, Serial0/0
============================================
Even with f0/0 and s0/0 configured with the addresses in any router, no host at its respective routers is able to ping the s0/0. Hosts are able to ping its ethernet ports.
See ping comand below:
From router KelliR
KelliR#ping 192.168.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.2, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms
KelliR#ping 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms
KelliR#ping 192.168.2.101
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.101, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms
KelliR#
==================================================================================
From router HelderR
HelderR#ping 192.168.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.3.1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/33/36 ms
HelderR#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms
HelderR#ping 192.168.1.101
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.101, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/34/36 ms
HelderR#
====================================================
From Host connected to KelliR
C:\>ping 192.168.1.1
Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=2ms TTL=255
Reply from 192.168.1.1: bytes=32 time=1ms TTL=255
Reply from 192.168.1.1: bytes=32 time=1ms TTL=255
Reply from 192.168.1.1: bytes=32 time=1ms TTL=255
Ping statistics for 192.168.1.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms
C:\>ping 192.168.3.1
Pinging 192.168.3.1 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.3.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
=====================================================
From Host connected to HelderR
C:\Users\Helder>ping 192.168.2.1
Pinging 192.168.2.1 with 32 bytes of data:
Reply from 192.168.2.1: bytes=32 time=3ms TTL=255
Reply from 192.168.2.1: bytes=32 time=1ms TTL=255
Reply from 192.168.2.1: bytes=32 time=1ms TTL=255
Reply from 192.168.2.1: bytes=32 time=1ms TTL=255
Ping statistics for 192.168.2.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 3ms, Average = 1ms
C:\Users\Helder>ping 192.168.3.2
Pinging 192.168.3.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 192.168.3.2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

Serial port reads unconventional characters

Hi,
     I'm using the serial port to read 32 8bit numbers and have been getting some strange characters read back.
    I've tested the hardware with Matlab which works fine but with Labview I get the following string
   À Ð à Ð àÿÐÿÐÿÐÿÐÿÐÿÐÿÐÿÐÿÐÿÐ À
   Since these are not standard characters I can't seem to convert them to any other format. I've also used an ActiveX control (AComPort) in Matlab to do the same thing and I get the identical string above, so its something to do with the format rather than an error in the reading I think.  However if I use AComPort to read one byte at a time (rather than a string) I get the correct numbers, so could I do the same thing in Labview?
Thanks for any help
Emrys

hi there
i bet there's something wrong with the serial port settings
- Enable Termination Char (T)
- Termination Char
- data rate
- data bits
- polarity
- stop bits
you can adjust these settings with the "VISA Configure Serial Port.vi". please check if the settings are correct.
you wrote "However if I use AComPort to read one byte at a time (rather than a string) I get the correct numbers", so try 8 databits, 1 stopbit, no parity and disabled termination character or see the documentation of AComPort .
Best regards
chris
CL(A)Dly bending G-Force with LabVIEW
famous last words: "oh my god, it is full of stars!"

How to empty Serial port buffer ???

Hi!
I am having problems with serial port. I want to clear i
serial ports buffer, but i dont know how to do this. I am receiving NMEA data through that port and every now and then i need to clear it because there are too much data and i dont need them all. Could someone please help me?

Hi,
Take a look at this link.
http://www.sc-systems.com/JavaDoc/Serialio.SerOutputStream.html
flush
public void flush() throws IOException
Causes any buffered data on the output stream to be written. Note: when using txDrain be advised that some OS's (like WinNT) do not provide a timeout on the OS level drain/flush call. In this case if handshake (flow control) is disabled from the far end your txDrain call will block until drain can complete. (i.e. until the handshake state changes). Because of this the default mechanism for flush is to watch the txBuffer. This will allow you to abort a stalled OutputStream since your code will not be locked up at the native level.
Throws: IOException
if an error occurs. Overrides:
flush in class OutputStream
However the above function and the class defining this is not provided by SUN.
I hope this helped.
Roopasri Vittal
Developer Technical Support
Sun Microsystems
http://sun.com/developers/support

Keyboard on serial port under Solaris 8

I've hooked a special keyboard into the serial port (/dev/ttya), and am trying to read from and write to it. I enable the port via "admintool" (with "initialize only - no connection" and only "software carrier" checked under options, and then set my port parameters via "stty" as needed. Then I can start up my C program to read/write to the keyboard. This works for a moment, but then "ttymon" seems to reset the port or something, which changes the port parameters and screws up my program. If I disable the port via "admintool", which kills "ttymon", then I can't set the port parameters as needed and run. I can enable the port, set the parameters, and then kill "ttymon", and then run my driver. This seems to work, but doesn't seem like the correct way to go about doing things. So what do I need to do? Any help would be appreciated. Thanks. Don

Hi donernsdorff,
You can disable ttya been monitored by ttymon and see if that helps. You can use pmadm command (Pls see man pages for details) to disable or change the port monitor settings. Hope this helps. Thanks. SUN/DTS

Sending Hex text files to the Serial Port

Hi,
Does anyone know or have any experience in how to open a Hex file, read
the data and send it down the serial port.
Regards,
Martin.

Martin Stanley wrote:
>
> Hi,
> Does anyone know or have any experience in how to open a Hex file, read
> the data and send it down the serial port.
>
> Regards,
> Martin.
Martin,
I have a vi that reads a hex file then sends the data out the serial port.
It waits for each byte to be echoed back before sending the next one.
As each hex number is read, it's converted to a decimal number. The number
is used as a decimal ascii code, the ascii character is then sent to the
serial port.
I'm not sure if this is the most efficient way to do it, but it works.
Walter

Serial Port Echo Disabling

Similar Messages

Maybe you are looking for