Flow Control - AMX VISUALARCHITECT 1.1 Manual

Table of Contents

Advertisement

If you need to modify a Diagnostic filter's information (such as System/Device/Port) you can:
1. Navigate to an empty Diagnostic filter slot and click the Modify button below the filter.
2. Select a previously unused Preset and store it with a new name.
3. Click the Remove button to remove this duplicate Preset from the specific filter slot.
4. Re-open the empty slot by clicking the Modify button, select the duplicated Preset and click Recall.
5. Change the necessary information (such as the System/Device/Port), then save it as the original
Preset name, and click the Update button.
6. Use the Incoming Message field to view all the internal system diagnostic messages that are
generated by a NetLinx master controller. This message field is a text box where you can select all
the text within it and then copy/paste it for storage.

Flow Control

Flow control dictates whether any handshaking is used. There are three possibilities: none (the most
common), hardware, and software.
Hardware handshaking involves the use of two additional conductors to send a 'Request to Send' (RTS)
signal between the devices. RTS is an output signal to the far end device that states it is OK to send data.
The 'Clear to Send' (CTS) connection is an input signal that receives the RTS from the far end.
When the RS-232 port is configured for hardware handshaking, no data is sent until the port receives a
'high' signal on the CTS pin from the RTS pin at the far end. Similarly, no data will be returned unless the
RTS pin goes 'high', indicating it is able to receive data. There is another level of hardware handshaking
using DTR and DSR, or Data Set Ready and Data Terminal Ready. These are primarily used by modems
to communicate with PCs. These modes are not used in AMX gear, and you will find no connections for
these signals.
Software handshaking uses data signals over the data wiring. This method is quite rare, and you should
contact Tech Support if you have any questions regarding it's use.
Unexpected Touch Panel Beeping
There are three main causes for unexpected touch panel beeping:
VisualArchitect v1.1
CONFIDENTIAL AND PROPRIETARY. COPYRIGHT, AMX LLC, 2006
Remove a diagnostic filter by clicking the Modify button below it (from the Diagnostics
dialog), then pressing the Remove button to delete this filter from the Diagnostics dialog.
Once a Preset is assigned to a specific Diagnostic filter "slot" (up to 8), its System:Device:Port
fields are greyed-out, and can't be modified unless the Preset in that slot is removed and
replicated with new information within these fields.
Device ID Conflict - There are two or more devices that are sharing Device ID's on the
current system. This is incorrect. Each device must have its own unique Device ID.
One common error is to have a touch panel emulating more than one device. For example, if
your touch panel is emulating 4 devices and is at Device ID 128, then it is using Device ID's
128,129,130, and 131. If another Device is at 130, you will get the panel beeping. This can
happen even if it is not the touch panel that is sharing Device ID's.
Low Power - If the touch panel is not receiving sufficient power, it is then likely to start
beeping. To check this, attach a separate power supply to the touch panel and see if the
beeping stops.
Voltage drop over longer lengths of cable can also pose a problem. Shorten the cable or
replace with a larger gauge wire.
Loose power / data connection will cause a panel to beep as it goes on / off the bus.
Appendix A: Troubleshooting and Support
155

Advertisement

Table of Contents
loading

This manual is also suitable for:

Visualarchitect v1.1

Table of Contents