RS485 short reply

koozoo

Ni-x100 Serial device (RS485) can control very short time response ?
Remotemicrophone which I try to control require the very short time polling.
Every 60msec device send to amx the polling request, amx shuold repry in 6msec.

I tried following, but amx rs485 send the polling about 50msec after receiving request.

Limits of the amx device?



DATA_EVENT[RMC]
{
STRING:
{
IF (FIND_STRING(RMC_BUF,"$80,$3D",1))
{SEND_STRING RMC,"$70,$8F" //POLLING}
}
}


Using timeline ....


DEFINE_VARIABLE

lTL_Time[1] = {20}

DEFINE_EVENT

TIMELINE_EVENT [1]
{
SEND_STRING RMC,"$70,$8F" //POLLING}
}

DATA_EVENT[RMC]
{
STRING:
{
IF (FIND_STRING(RMC_BUF,"$80,$3D",1))
{TIMELINE_CREATE(1,lTL_Time,1,TIMELINE_ABSOLUTE,TIMELINE_REPEAT)}
}
}

vining

Post a link to the protocol if you can cuz that doesn't sound right. I could see the protocol saying commands should be spaced at least 60 ms apart but making you poll at that rate seems wrong.

koozoo

My explanation was insufficient,,,

AMX reply between 3msec after receiving request from device.
Is it possible?


device amx


---

---

poling request

---

>----
| | |
| | 2msec |
| v |
| <

---

poling reply

---

|
| |
| 5msec v
|
|
|
v
60msec
--- ---next poling request

---

>----
| | |
| | 2msec |
| v |
| <

---

poling reply

---

|
| |
| 5msec v
|
|

vining

To me that looks backward. I would think AMX would poll and the device would respond in 2ms. Not sure what the 5ms represents and the 60ms would be the earliest the next command could be sent and processed by the device. I would never poll that quickly but i would send commands that quickly. Actually i would even slow that down to 150-250ms.

I suggest playing with the device, see what works, then poll and send command at intervals that suit your needs and the device's capabilities.

ericmedley

You could probably create a test for yourself. You could connect a couple of the serial ports together crossing the TX and RX. Then write some code to send and receive messages and time the responses using the system clock. That will at least give you some data on just how fast things do work and remove one of the variables from the problem.

Hedberg

Perhaps this is a problem with half duplex RS485. If the device connected to allows for full duplex, wiring the DB9 on the AMX as RS422 and using 485 disabled should allow for full duplex RS485 operation. My understanding is that all enabling RS485 does is allow for half duplex operation with the transmit and receives being the same wires (see any master manual for shorting transmits and receives for half duplex RS485).

Hedberg

Ok. RS485 is a balanced, 3-wire, half duplex communications scheme which allows for multiple connections on the same bus. In order to avoid data collisions because all devices transmit and receive data on the same wires, devices are supposed to remain in receive mode until no other device on the bus is transmitting and then the device is allowed to go into transmit mode. Some setups may have a master device which may transmit at will and slave devices which will transmit only in response to queries from the master device.

It's not clear to me how the serial port on an AMX master handles the switch between idling receive mode and transmit mode. There doesn't appear to be much information in the manuals describing how it works. But, it seems reasonable to me that any attempt to transmit on an AMX serial port with RS485 enabled would require that the data be buffered until a delay following any data reception. In other words, it would seem probable to me that the port would not go into transmit mode until some time following the receipt of the last data, this delay being imposed in order to avoid data collisions.