1. Loopback Test Serial Port Uart
2. Loopback Test Serial Port

A: Perform a 'Loopback' test using a Terminal Program that lets you Open a serial port to send and receive characters. To check both inputs and outputs, the outputs are connected to the port inputs. To check both inputs and outputs, the outputs are connected to the port inputs. A simple serial interface loopback test, called paperclip test, is sometimes used to identify serial ports of a computer and verify operation. It utilizes a terminal emulator application to send characters, with flow control set to off, to the serial port and receive the same back. Performing USB and Serial Converter Loopback Test To confirm operation of the USB and Serial converter the following information will explain how to perform a loopback test using HyperTerminal. Abstract away your serial port comms behind an interface so that you can code your app against the interface and then test with a 'fake' implementation. When you've got the hardware for the real thing, you can code up the 'real' implementation of the interface and swap out the fake one. Plug the loopback into the RJ-45 connector on the port in question on the VWIC. Configure the channel-group on the controller. Configure an IP address on the serial interface. USB Serial RS232 Loop-back test and troubleshooting A loop-back test can verify if your USB to serial RS232 adapter has been installed properly and if it can send and receive data as intended.

I'm about to start developing a small app (C#) that communicates with a PLC and a testing unit via Serial Ports - this is my first venture into this area.

In essence, I am going to send the PLC a signal to start an operation, and then I am going to wait for the result of that operation from the test unit (which will be independently communicating with the PLC) to return a ASCII string.

Depending on the content of that string, I may want to listen to a signal from the PLC..

It's all new to me, so at the moment, I'm just researching System.IO.Ports.SerialPort; digression: are there third part products out there than simplify interaction with the Serial Port, or are the built-in classes as good as you will get? I'm thinking of ease of use as opposed to better features.

However, it will be a few weeks before the hardware is available for development and testing, so I was wondering how I could simulate communication to/from the serial port so that I can start developing my app?

[I don't yet know how the PLC and the PC are due to communicate - I understand it will be binary rather than text, but at the moment, that is all I know.]

Anthony MastreanCJMCJM

6 Answers

Abstract away your serial port comms behind an interface so that you can code your app against the interface and then test with a 'fake' implementation. When you've got the hardware for the real thing, you can code up the 'real' implementation of the interface and swap out the fake one.

So for example, you'd have an interface

and you'd code your app against that interface using a fake implementation:

Hope that helps!

DavidGougeDavidGougefryguybobfryguybob

There are two pieces of software that I have found invaluable while doing serial port work.

Free Serial Port Monitor

Despite the cheesy name, it is actually quite useful. Note that you should have it stop listening to your port if you go to unplug a USB-to-Serial converter. Otherwise it can crash (well.. wait indefinitely on exit, which is annoying). It doesn't have to put itself in the middle of a serial connection to sniff data. It monitors the IO using the Win32 API.

Franson Serial Port Tools

Or. any loopback software really. There are lots out there. This allows you to send data and receive it within software. If you end up doing any GPS work, Franson also has a nice GPS simulator so you don't have to sit outside the whole time to debug code.

Finally, if you have had enough with the built-in serial class and its horrendous shortcomings, then you need a replacement, and going straight to the Win32 API will take forever.

CommStudio

I have found CommStudio to be absolutely rock solid. Quite frankly, after spending 5 months researching and buying other options, it is the only one that works perfectly with removable USB adapters. All of the other solutions have issues when the device is plugged back in. You can download their free 'Express' version here: http://www.componentsource.com/products/commstudio/downloads.html?rv=42917

BradBrad

There is another resource out there that emulates serial ports for windows if anyone else is still looking for decent serial debugging tools.

The 32-bit version is free and seems pretty decent. It's called Virtual Serial Ports Emulator.

jlafayjlafay

I like David's answer above but if your looking to do integration tests and actually test your serial port communication I have used and application called ViN soft virtual serial cable in the past to basically create 2 serial ports on your machine that are connected by a virtual cable.

Also if you have a serial port on your development machine you could use it to connect to another machine that has a serial port and write an application that will basically simulate the communication of the PLC.

I would prefer to use a combination of both David's method and this method to ensure proper testing.

Cole WCole W

I have wrote an article on this topic using Virtual Serial Port Driver 9.0 standard using Microsoft SerialPort Class (Sytem.IO.Ports), it is of course possible to use any other comm port tool.

In the software I create 2 virtual ports COM1 and COM2.

I use COM1 to emulate as data sender.

I use COM2 to receive what ever being send from COM1.

This is helpful if you are developing Embedded or IoT solution.

Emulator (in this example as random accelerometer)

And my data receiver is almost similar

Disclaimer: the link of this guideline refer to my personal web site.

maytham-ɯɐɥʇʎɐɯmaytham-ɯɐɥʇʎɐɯ

Not the answer you're looking for? Browse other questions tagged c#serial-portsimulation or ask your own question.

Contents

Introduction

A common issue in VoIP networks with a digital interface connection to a telecommunications provider (telco) is that the ISDN or channel associated signaling (CAS) circuit does not come up or stay up. Such issues can be complex because:

1. Faulty components might reside in several places - for example, within the Cisco domain or in a third-party (telco) domain.
2. Multiple components impact the status of the ISDN Primary Rate Interface (PRI) or T1 CAS circuit. The problem could be mismatched configuration across the telco interface, which leads to clock slips, line/path violations, a damaged cable, a bad card, or telco issues.
3. The Cisco Technical Assistance Center (TAC) does not directly deal with third party organizations.

How can there be efficient and effective progress on the issue? This document describes an important and useful troubleshooting method, known as loopback testing, and covers various loopback testing techniques.

Notes:
Use the Command Lookup Tool (registered customers only) in order to obtain more information on the commands used in this document.
The Output Interpreter Tool (registered customers only) supports certain show commands. Use the Output Interpreter Tool in order to view an analysis of show command output.
Refer to Important Information on Debug Commands before you use debug commands.

Background

Loopback testing is a very effective way to isolate a failing T1 (or E1). The basic idea behind loopback testing is:

1. Start at the Voice/WAN Interface Card (VWIC) on the Cisco gateway.
2. Perform loopback testing. If the testing is successful, it eliminates the VWIC as the problem component.
3. Move the loopback testing out to the next component, and repeat Steps 1-3. Progress in stages toward the telco point of demarcation (demarc).

The components you should try to eliminate as problematic include the VWIC (card and port) and the cable run (up to the SmartJack).

SmartJack

The SmartJack is often referred to or is involved in TAC calls on T1/E1 issues. A SmartJack is a type of network interface device (NID) that terminates the PRI/T1 from the Cisco gateway and that also provides some diagnostic capabilities.

A very common capability provided by a SmartJack is loopback, where the signal from the telco is transmitted back to the telco.

Telcos consider everything connected to the inside of the SmartJack as the local loop and consider all local loop equipment the responsibility of the customer. This figure illustrates a SmartJack.

Loopback Test Types

This figure provides a general overview of loopback testing.

This document describes three types of loopback tests:

• Soft loopbacks (also known as software loops or soft loops) are commands from test equipment that cause a network interface unit (NIU) or CSU to automatically send traffic back towards the sender.

• A hard loopback (also known as a hard loop) is a physical loop created by wire. A loopback plug or an RJ-48X connector can create this hard loopback.

• The telco-assisted loopback is done with the assistance of the telco. You should explore this option only after you rule out the Cisco gateway and the cable run (to the telco demarc) as the source of problems.

See Loopback Tests for T1/56K Lines for detailed descriptions of loopback tests. You can safely ignore the references to CSUs and Data Service Units (DSUs) in this document. In Cisco voice gateways, CSUs and DSUs are integral to the VWICs on Cisco voice-enabled gateways.

Soft Loopback

Note: Soft loopback is intrusive and will impact service.

Soft loopback testing is accomplished with a set of Cisco IOS^® software configuration commands on the Cisco gateway. The commands cause the WAN interface card (WIC) driver to automatically send traffic back towards the sending T1/E1 port.

Soft loopback does not require any hardware changes or re-configuration, as shown in this figure.

This procedure describes how to test a soft loopback:

1. Put the T1 or E1 in local loopback mode.
2. Configure the channel-group on the controller.
3. Configure an IP address on the serial interface.
4. Perform Internet Control Message Protocol (ICMP) pings, and verify that the counts for 'packets input' and 'packets output' increment. See Hard and Soft Loopback Verification for details of this step.

This is an example of the configuration of the channel-group on the controller:

Hard Loopback

Note: Hard loopback tests are intrusive and will impact service.

In a hard loopback, a special loopback plug is used in order to loop the traffic from the T1 port back into the T1 port. This figure illustrates the setup for hard loopback.

There are two approaches to test a hard loopback: Autodock vina download.

1. Test as an ISDN circuit.
2. Test as an IP interface.

ISDN Circuit

The first approach, test as an ISDN circuit, offers limited scope for testing and verification.

ISDN Layer1 can be tested. If the VWIC is working correctly, the show controller t1 command produces output similar to that shown in this example:

ISDN Layer 2 can be partially tested. While you can verify that Set Asynchronous Balanced Mode (SABME) messages flow across the interface, the other, usual Q.921 messages, such as RR, RRf, and RRp, are not seen. Instead, you see this type of output:

This is expected. For the ISDN interface to work, one side must be configured as a protocol network, and the other side as a protocol user. However, this is not possible since there is only one interface with the loopback. Consequently, you see that the ISDN status oscillates between AWAITING_ESTABLISHMENT and TEI_ASSIGNED.

ISDN Layer 3 never comes up.

Another limitation with this approach is that it does not work if the T1 is configured as a T1 CAS.

One advantage of this approach however, is that no configuration change is required on the Cisco IOS software. The only procedure is:

1. Make or buy a loopback plug.
2. Plug the loopback into the RJ-45 connector on the port in question on the VWIC.

Use the show controller t1 command in order to verify that the T1 controller comes up, and use the debug isdn q921 command in order to verify the flow of Q.921 messages. ISDN Layer 3 is, of course, not possible.

IP Interface

The other approach, test as an IP interface, is also known as 'test as a data T1.' This approach lets you conduct ICMP ping tests, which seems better because you can verify that the VWIC (card and port) is good all the way up to Layer 3. Note, however, that the Layer 3 is Open System Interconnection (OSI) Layer 3, not ISDN Layer 3.

Tip: This method is versatile because it works regardless of whether the T1 is being used as an ISDN interface or as an T1 CAS interface.

This procedure describes how to test as an IP interface:

1. Make or buy a loopback plug.
2. Plug the loopback into the RJ-45 connector on the port in question on the VWIC.
3. Configure the channel-group on the controller.
4. Configure an IP address on the serial interface.
5. Perform ICMP pings, and verify that the count for 'packets input' and 'packets output' increments. See Hard and Soft Loopback Verification for details of this step.

See the procedure to create a loopback plug for a T1 CSU/DSU in Loopback Tests for T1/56K Lines.

This is an image of a T1/E1 loopback plug:

This is an example of the configuration of the channel-group on the controller:

The show controller command produces results similar to these:

Hard and Soft Loopback Verification

Loopback testing to verify the interface at ISDN Layer 3 level is not possible because ISDN Layer 2 does not come up on a loopback setup. Therefore, only testing as an IP interface is possible. Once the configuration steps are complete, perform ICMP pings:

Check the interface counters in order to verify that the count for 'packets input' and 'packets output' increments. This is a sample output of the show interfaces serial slot/port command:

Note: Perform an extended ping in order to test for possible flapping conditions.

Cable Run Test

Once you determine that the VWIC is working correctly, use this procedure to test and eliminate the cable run (to the telco demarc) as the source of problems:

1. Remove the loopback plug from the VWIC port.
2. Connect the cable to the VWIC port.
3. Disconnect the cable from SmartJack.
4. Plug the loopback to that end of the cable run.
5. Perform loopback tests.

If the ICMP pings are successful, the test is succesful, which indicates that the cable is fine. If there are cuts or other damages to the cable run, you see that the T1 controller stays down, caused by the loss of signal (LOS):

Note: Non-zero line and path code violations do not necessarily indicate problems with the cable. When you move the loopback plug from the VWIC port to the end of the cable run, line and path code violations are triggered. After you move the loopback plug, you can clarify this if you first clear the controller counters with the clear controller t1 0/0/0 command, then see if line and path code violations increment.

T1 CAS

Use the procedure described in IP Interface.

E1

There is no difference between loopback testing for a T1 or an E1.

Telco-Assisted Loopback

Note: Telco-assisted loopback tests may impact service.

The telco (also known as the carrier, telephone company, telecommunications provider, or service provider) is the provider of the T1/E1 circuit service.

If you are unable to perform the hard and soft loopback tests or if the hard and soft loopback tests reveal that that the Cisco gateway and the cable run (to the telco demarc) are working correctly, telco-assisted loopback might be an option.

There are two possibilities:

1. Ask the telco to provide loopbacks towards your premises from the telco switches. Monitor the looped circuit from the router. In this scenario, test the circuit as an ISDN interface.
2. Contact your telco, and ask them to perform a loopback test to the SmartJack. The telco can test the line from the central office and does not need to have test equipment at your site. Usually, the telco can activate the loopback remotely and does not need to have personnel at your site. When looped back, your equipment is disconnected from the line.

Loopback Test Serial Port Uart

This is a figure of the two possibilities for telco-assisted loopbacks:

Loopback Test Serial Port

Related Information