*Refreshing this page at any point will restart the troubleshooting guide.
Start by enabling Crimson's Balloon Help feature (Help-Balloon Help-When Mouse Over), as it will be referenced throughout this guide.
Intermittent Comms - Values flashing to dashed lines
Values are Showing, but not Changing or are Incorrect
First, verify that the port is wired correctly.
RS232 - Show Port Details
RS485 - Show Port Details
Figure 1 shows the connector for the RS232 port on the device.
Figure 1.
Pin 1 - Clear to Send
This pin is used by VERY few drivers, can be monitored when using the Raw driver with the PortGetCTS function.
Pin 2 - Receive
The pin where the unit is listening for data, connect it to the pin of the other device which is sending data.
Pin 3 - Common
0V reference, on units without isolated communication ports, this is tied to the DC power supply common.
Pin 4 - Common
0V reference, on units without isolated communication ports, this is tied to the DC power supply common.
Pin 5 - Transmit
The pin the unit will send data on, connect it to the pin of the device which will be listening for data.
Pin 6 - Ready to Send
This pin is used by VERY few drivers, can be controlled when using the Raw driver with the PortSetRTS function.
Figure 2 shows the connector for the RS485 port on the device.
Figure 2.
Figure 3 shows a block diagram of the port's internal connections.
Figure 3.
Pin 1 - Transmit B
Internally tied to pin 7.
This pin is internally pulled up to 5VDC through a 130K ohm resistor.
2-wire mode: In 2-wire mode, this pin is used for transmitting and receiving. It should be connected to the pin on the other device that is biased towards positive voltage.
4-wire mode: In 4-wire mode, this pin is used for transmitting. It should be connected to the pin on the other device that is listening for data and biased towards positive voltage.
Pin 2 - Transmit A
Internally tied to pin 8.
This pin is internally pulled down to 0VDC through a 130K ohm resistor.
2-wire mode: In 2-wire mode, this pin is used for transmitting and receiving. It should be connected to the pin on the other device that is biased towards 0V.
4-wire mode: In 4-wire mode, this pin is used for transmitting. It should be connected to the pin on the other device that is listening for data and biased towards 0V.
Pin 3 - Receive A
This pin is internally pulled down to 0VDC through a 130K ohm resistor.
2-wire mode: In 2-wire mode, this pin is not used.
4-wire mode: In 4-wire mode, this pin is used for receiving. It should be connected to the pin on the other device that is sending data and biased towards 0V.
Pin 4 - Receive B
This pin is internally pulled up to 5VDC through a 130K ohm resistor.
2-wire mode: In 2-wire mode, this pin is not used.
4-wire mode: In 4-wire mode, this pin is used for receiving. It should be connected to the pin on the other device that is sending data and biased towards positive voltage.
Pin 5 - Transmit Enable
This pin is only used for DH485 communications.
Pin 6 - Common
0V reference, on units without isolated communication ports, this is tied to the DC power supply common.
Pin 7 - Transmit B
Internally tied to pin 1.
This pin is internally pulled up to 5VDC through a 130K ohm resistor.
2-wire mode: In 2-wire mode, this pin is used for transmitting and receiving. It should be connected to the pin on the other device that is biased towards positive voltage.
4-wire mode: In 4-wire mode, this pin is used for transmitting. It should be connected to the pin on the other device that is listening for data and biased towards positive voltage.
Pin 8 - Transmit A
Internally tied to pin 2.
This pin is internally pulled down to 0VDC through a 130K ohm resistor.
2-wire mode: In 2-wire mode, this pin is used for transmitting and receiving. It should be connected to the pin on the other device that is biased towards 0V.
4-wire mode: In 4-wire mode, this pin is used for transmitting. It should be connected to the pin on the other device that is listening for data and biased towards 0V.
Is the port wired correctly? 
Did wiring the port correctly resolve the issue?
Click on the port being configured to verify that the port settings match between the two devices: Baud Rate, Data Bits, Stop Bits, Parity, and Port Mode (RS485 only).
Do the port settings match?
Did correcting the port settings resolve the issue?
If applicable: there are several drivers, including DH485 and BACnet, that have settings for the Crimson device being programmed. Reference the Balloon Help for these settings and ensure they will work in the system.
Will the driver settings work for this system?
Did correcting the port settings resolve the issue?
Several drivers have a ping register setting. This register is read to determine if the device is online, prior to reading data for mapped tags, gateway blocks, and direct references to the device. This ping can be disabled for some drivers, such as Modbus, by setting the ping register to 0. Please note that disabling the ping will cause unreliable values for CommsErrror, IsDeviceOnline, and GetDeviceStatus.
Does the ping register exist in the remote device, or has the ping been disabled?
Did correcting the ping register resolve the issue?
Verify that all gateway blocks, tags, and direct mappings are referencing valid registers in the external device. Some devices have all of their memory accessible via communications by default, but other devices require the memory to be allocated or that registers be created prior to being available via communications.
When the Crimson device encounters a communication error, timeout or negative reply, it stops scanning the external device and starts over. If the first item it attempts to read is invalid, then it will not continue attempting to read any other items from that external device.
Red Lion recommends starting with a new simple 1-tag application to verify port wiring and other settings are correct.
Do all of the memory locations/registers exist in the external device?
Did creating the registers in the external device resolve the issue?
The ability to disable communications is helpful during development, but leaving them disabled will result in the Simulate As values being used (which are 0 by default).
Are Communications Enabled?
Did enabling Communications help to resolve the problem?
Preempting other devices may result in the other devices never getting a chance to communicate, this setting should be set to No on all devices.
Did setting Preempt Other Devices to No on all of the devices resolve the issue?
Spanning reads allows the system to read large blocks of data that span the required registers, but may also include registers that are not being accessed. It also assumes that all of the registers in the span are the same size.
Some devices may contain registers that cannot be read, others (such as the Emerson ROC devices) contain registers of variable length; in both cases, Spanning Reads should be Disabled.
Did disabling Spanning Reads resolve the problem?
Verify the data type of the register in the target device. Treating an Integer as a Floating-point value will typically result in 0 being displayed.
Does the Crimson data type match the external device?
Did fixing the mismatch resolve the issue?
Incorrect scaling could result in unexpected results, first, disable the scaling to ensure the value is changing. Then refer to the Crimson: Scaling Tech Note for information on scaling tags in Crimson.
Did disabling or correcting the scaling correct the problem?
Call us on the toll-free Tech Line: 877-432-9908 or the Support button on the lower right to fill out a contact form.
It is the customer's responsibility to review the advice provided herein and its applicability to the system. Red Lion makes no representation about specific knowledge of the customer's system or the specific performance of the system. Red Lion is not responsible for any damage to equipment or connected systems. The use of this document is at your own risk. Red Lion standard product warranty applies.
If you have any questions or trouble contact Red Lion Technical Support by clicking here or calling 1-877-432-9908.
For more information: http://www.redlion.net/support/policies-statements/warranty-statement
