Chipkin Automation Systems - Articles » RS485

Fix for mouse jumping around the screen randomly when connecting a USB to Serial converter

Steven — Fri, 14 Oct 2011 17:54:52 +0000

The problem:

When I connected my serial to USB converter (USB-Comi) to my computer my mouse pointer would randomly jump around the screen making it impossible to do any work. I tried reinstalling both the serial to USB converters drivers and my mouse drivers without an success.

The solution

After some searching I found this article How to fix “crazy mouse” syndrome with USB serial adapters that was able to resolve the issue I was having.

You need to disable serial enumeration on the advanced settings of your virtual serial port. The serial port will still work and it should resolve your “crazy mouse” problem.

CAS Gateway UL RS232 to RS485

Steven — Wed, 08 Jun 2011 23:05:47 +0000

To switch the CAS Gateway UL box from its default RS232 to RS485 you will need to open the box and change some of the jumpers.

For example this is a photo of the board set up in RS-232

USB-COMi-SI-M USB-to-Optical isolated RS-422/485 Adapter

Steven — Tue, 18 Jan 2011 17:37:13 +0000

Wiring diagram RS485.

[USB-COMi-SI-M, pin 1] (-) Negative
[USB-COMi-SI-M, pin 2] (+) Positive
[USB-COMi-SI-M, pin 5] Ground

[USB-COMi-SI-M, Sw1] OFF
[USB-COMi-SI-M, Sw2] OFF
[USB-COMi-SI-M, Sw3] ON
[USB-COMi-SI-M, Sw4] ON

Driver Downloads

Download USBCom-CDM

Useful tools and applications for Modbus

cpascu — Mon, 01 Mar 2010 08:00:47 +0000

Here’s a useful list of tools to use with Modbus devices:

CAS Modbus Scanner (download)
- Allows us to retrieve coils, inputs, holding registers, and input registers from a Modbus enabled device.
Modbus RTU Parser (download)
- Allows us to analyze an RTU message and see what type of message it is, if there are any errors, what device the message came from, etc…
Modbus TCP Parser (download)
- Allows us to analyze an TCP message and see what type of message it is, if there are any errors, what device the message came from, etc…
Wireshark (homepage)
- Used for capturing Modbus TCP messages coming through the ethernet port.
- A full list of the captured data can be found here.
Modbus Specification (pdf)
- Official specification of the Modbus Application Protocol
Nerds In Control (homepage)
- Very useful community website for automation professionals.
- An excellent place to ask for Modbus help or help others with their Modbus problems.
Modbus Simulator (download)
- Used for simulating a Modbus server for testing and learning purposes.
Simply Modbus (download)
- Good Modbus TCP and RTU software, an alternative to our CAS Modbus Explorer and Scanner.
- Website provides good tutorials on Modbus.
Capturing with serial connections (tutorial)
- How to capture Modbus messages with a serial connection using free tools like PuTTY.
Modhopper (info)
- Allows connecting up to 128 Modbus devices through wifi to any Modbus network.

Feel free to suggest other tools that you find useful and I will add them to the list.

CAS Modbus Scanner v1.02aB

cpascu — Wed, 03 Feb 2010 20:43:18 +0000

CAS Modbus Scanner is a utility to retrieve coils, inputs, holding registers, and input registers from a Modbus enabled device. Values retrieved from the device can be viewed in many different formats including Binary, HEX, Uint16, Int16, Uint32, Int32, and Float32.

Features:

Can read; coil status (0xxxx), input status(2xxxx), input registers (3xxxx), and holding registers (4xxxx)
Data is viewable in Binary, HEX, Uint16, Int16,Uint32, Int32, and Float32
Multiple connections
Works with RS232 and RS485, TCP
Easy to use interface
100% Free to use, no registration required.

New

Works with Modbus TCP
Works on Windows Vista and Windows 7 (32bit and 64bit)

FieldServer 485 Connection Diagram to Isolator ICD102A (Black Box)

skapoor — Mon, 25 May 2009 09:06:07 +0000

This diagram shows how to connect a FieldServer FS20 series to an ICD102A optical isolator using a 2-wire RS 485 connection. FieldServer’s only support 2 wire connections.

Datasheet for the Black Box RS485 Isolator/Repeater can be found here: Blackbox Network Services

RS485 Networks – Multiple Protocols

pchipkin — Fri, 15 May 2009 21:52:19 +0000

RS485 defines the physical layer of the network. You may use it as you want. However, since the trunk is shared it is important that no two (or more) devices talk at the same time. If they do this will produce collisions and the corruption of both messages.

The following applies for both half and full duplex RS485.

You can have any number of protocols on the same 485 trunk provided that two or more devices do not talk at the same time.
The consequences of this statement are
1. You can only use more than one protocol if they are poll/response type protocols like Modbus Rtu or Rockwell DF1.
2. If you have a token passing protocol (such as Bacnet mstp) you cannot use another protocol on the same trunk
3. Only one device can be the master for the multiple protocols. The reason is that the master decides when to poll and how long to wait for a response.

Thus, If you have full control over one rs485 port you could use that port to send a poll using protocol#1, wait for a response and then send a poll using protocol#2. If you do not have full control (ie. You are letting two applications which are not co-ordinated share the port) then you cannot run two protocols.

RS485 on a Scope

cpascu — Mon, 27 Apr 2009 23:26:49 +0000

Using an oscilloscope on a RS485 network. For reference purposes we present some scope captures of a typical RS485 line.

In this capture we had our scope leads connected to the positive signal conductor and ground.

Zone A: Idle State

Zone E: Idle State with Noise
This is the state of the network when all the transmitters have released the line. In this state the conductors float. In many ways this is the most dangerous state for a 485 network to be in since the voltage levels are not defined and vary depending on factors such as the ground potential between devices. If the voltage floats to a level where it looks like a signal then you will see noise bytes on the line. Once a device starts transmitting it pulls the line to a known voltage level so the floating problem is eliminated. Its usually quite easy to recognize these noise bytes because all messages look good but there is noise that precedes the message. Idle state biasing can be used to eliminate this problem because it has the effect of holding the line at a ‘known’ voltage for the duration of the idle state. Another source of idle state noise is not using the 3rd conductor – the so called signal reference common.

Zone B: The device has enabled it transmitter but has not started transmitting. The line is driven to a known state. The duration of this phase can be controlled by configuration in some devices. If it is too short then it is possible that some of the front of the message may be lost.

Zone C: Unless you have a very high speed scope and the scope can takes a huge number of samples you are unlikely to see each bit in the message. In this capture we can see the bytes (roughly speaking) but not the bits. We were forced to accept this compromise because the number of samples we could capture at a sampling rate high enough to see the bits would mean that we could only capture the 1st couple of bytes of the message and we would have to set the trigger to ignore zone B. Except with a very expensive scope you will be unlikely to be able to see the whole message and all the bits.

Zone D: We have finished transmitting but the transmitter is still enabled. Normally the device should disable its transmitter as soon as possible after transmitting the last stop bit of the message but since that can be difficult to achieve in the hardware, many devices run a timer to make sure they don’t disable the transmitter too soon. The problem with this approach is:
1) The longer the time the more potential bandwidth is lost.
2) The receiving device may have already processed the message and try to send a response by enabling its own transmitter causing collisions.

Probes on plus and minus conductors. Segment connected to slave device.

Probes on plus and minus conductors. This chart represent the capture from a master device with no slaves connected to the network leaving the cable ends to float.

CAS Modbus Explorer

cpascu — Mon, 27 Apr 2009 23:19:26 +0000

Modbus communications not working ? How do you know what’s wrong – is it the baud rate, the parity or even the address? There are so many things that can affect communications.

The Modbus protocol does not support discovery. There is no broadcast message that you can send that will make a slave respond with its port and address settings. The protocol allows for broadcast messages to be sent but doesn’t demand that every vendor supports this feature.

Use the CAS Modbus Explorer to find the correct port settings and the correct slave address.
The tool automates the process of trying all the combinations and reports the results. We provide burst and standard mode. In burst mode we send messages to all the possible slave address before waiting for a reply from any of them. This dramatically improves the time required to do the discovery.

The tool works for RS232 and RS485 by allowing you to search for a single device or multiple slaves. To connect to a RS485 network from your laptop you simply need a USB-to-485 converter.

Here is the problem – there are thousands of combinations:

Baud 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200
Parity, None, Odd, Even
Stop Bits 1, 2
Data Bits 7, 8
Address 1-254

If you had to manually search/test all these combinations it will take you ages. Relax, go for lunch and let the CAS Modbus Explorer do all the work for you.

Reducing latency on com ports

pchipkin — Fri, 06 Mar 2009 23:54:16 +0000

When a BYTE is sent from a serial device (BACnet MSTP thermostat) to a USB to 232/485 converters (USB-COMI-SI-M) it is cached on the USB converter until one of two things happened.

Transfer size – More then x BYTES are collected or
Latency timer – More then n Milliseconds (ms) expirer.

By default most ‘off the self’ USB to serial converters have a latency timer of 50ms and a transfer size of 4096 BYTES

The can be a major problem for PC utilities monitoring a serial network. The PC doesn’t get the BYTES fast enough to respond to the serial device before it times out.

For example:

On a network with a BACnet MSTP thermostat and a RS485 to USB converter connected to a PC. The BACnet MSTP thermostat will send a poll to the PC and will expect the PC to respond within 100ms. If the thermostat does not receive a response within this time the thermostat will assume that the device has gone offline. When the USB to 458 converter receives the message it will stay in its buffers for 50ms before being sent to the PC. Depending on the message it may take longer then 50 ms for the PC to respond to the poll and the thermostat will consider the PC offline.

Luckily we can set the Transfer size, and latency timer.

Most USB to 485 devices that I have used have the ability to set the transfer size and the latency timer.

Start menu–> Settings –> Control panel –> device manager –> Ports (COM & LPT) –>{Select your USB to RS485 converter}
Right click and select “Properties”
Select the “Port Settings” tab
Click the “Advanced” button
Change the Latency Timer (mSec) to 1 or the lowest possible setting.
Change the USB Transfer sizes to 64 or the lowest possible settings
Save and close.