Archive for the 'RS485' Category

Useful tools and applications for Modbus

Published by cpascu March 1st, 2010 in Modbus, RS485 and Utilities and tools. 0 Comments

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.

    Did you like this post?

    Subscribe To The RSS Feed!
    To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

    Do you have a question?
    We will do our best to try and solve any building automation, protocol, integration problem you may have

CAS Modbus Scanner v1.02aB

Published by cpascu February 3rd, 2010 in Modbus, RS232 and RS485. 0 Comments

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)

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

FieldServer 485 Connection Diagram to Isolator ICD102A (Black Box)

Published by skapoor May 25th, 2009 in RS485. 0 Comments

fieldserver-485-to-485-isolator

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

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

RS485 Networks – Multiple Protocols

Published by pchipkin May 15th, 2009 in RS485. 0 Comments

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.

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

RS485 on a Scope

Published by cpascu April 27th, 2009 in RS485. 0 Comments

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

plus_gnd_connected_bytes

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.

plus_minus_connected

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

plus_minus_not_connected

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.

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

CAS Modbus Explorer

Published by cpascu April 27th, 2009 in Modbus, RS232, RS485 and Utilities and tools. 0 Comments

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.

modbusexplorer

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.

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

Reducing latency on com ports

Published by pchipkin March 6th, 2009 in BACnet MSTP, RS232 and RS485. 0 Comments

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.

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

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

Why can’t I change to 76800 baud rate on PC?

Published by cpascu November 19th, 2008 in BACnet MSTP, RS232 and RS485. 0 Comments

Q: Why can’t we change to a 76800 baud rate on a PC but are able to on some devices?

A: The reason for this is that the the standard 16C550 PC UART is too slow to keep up with the signals coming in and out. 76800 is not a standard multiple of the UART clock frequency.

Devices can be customized and therefore allow baud rates of 76800. If your PC has a customizable COM port card where you can program the bit clock then you would be able to set this value.

There is no fix for this, but if you find a converter that can change 76800 to a higher UART this could be a work around.

The standard frequencies are:

  • 150
  • 300
  • 1200
  • 2400
  • 4800
  • 9600
  • 19200
  • 38400
  • 115000
Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

Four (4) Jumpers are required to connect a FS2510 to a 2-wire RS485 System

Published by cpascu November 10th, 2008 in Cables, FieldServer, RS485 and Uncategorized. 0 Comments

In early versions of the FS2510 the serial LED does not flicker even when
there is normal RS485 activity.

Devices with firmware version 5.12k are known to require a firmware upgrade.
Contact Tech support for help.

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

Cable Specifications for RS485 Networks – BACnet MSTP

Published by pchipkin October 8th, 2008 in BACnet MSTP, Cables and RS485. 0 Comments

The BACnet spec defined the media for MSTP as follows (2004) ;

“An MS/TP EIA-485 network shall use shielded, twisted-pair cable with characteristic impedance between 100 and 130 ohms. Distributed capacitance between conductors shall be less than 100 pF per meter (30 pF per foot). Distributed capacitance between conductors and shield shall be less that 200 pF per meter (60 pF per foot). Foil or braided shields are acceptable. The maximum recommended length of an MS/TP segment is 1200 meters (4000 feet) with AWG 18 (0.82 mm2 conductor area) cable. The use of greater distances and/or different wire gauges shall comply with the electrical specifications of EIA-485.”

Did you like this post?

Subscribe To The RSS Feed!
To catch many more articles like this in the future, make it easy on yourself and subscribe to me via RSS. You will not regret it!

Do you have a question?
We will do our best to try and solve any building automation, protocol, integration problem you may have

« Previous Entries