There is no mechanism that lets the host computing device know when an analogue input has changed state. Rather the host computer (PC, Tablet, Phone, Raspberry PI etc) needs to continually poll the ED-549 to get it to return the current input value from one or more of its analogue input
channels.

The computer sends the request to the ED-549, eg the Ascii string #010 command the
ED-549= device01 to read the analogue input of channel 0.

The request travels across the network and arrives at the ED-549.
The ED 549 processes the command and recognises it as a valid command.

The ED-549 instructs it’s Analogue to Digital Convertor/ Programmable Gain Amplifier start a conversion on the requested input channel with the requested input voltage range, the channel and Gain are set and a settling time of:

• THE ADC takes less than 1/12 of a second = <83 milliseconds
• The ED-549 formats the data packet for the reply
• The ED sends the data packet over the network as an Ascii string E.g. >+04.987

In the above, Network Latency obviously has a delaying effect on the number of commands the ED device will receive in any period of time. On a very busy network, fewer commands will get through successfully due to other network travel, this results in lost TCP/IP packets and retransmission of the command reducing network bandwidth.

In a normally busy company network this should not be a problem.

The ED range are designed to be able to process 200 commands per second so that they may suit the process control and factory automation world where typically 100 reading per second are more than adequate.

Whilst the ED-549 can respond to 200 commands per second, the Analogue to Digital convertor CANNOT convert faster than 12 samples per second.

I.e. the ED-549 can respond to the $01M command etc with its module name.
But you cant get more than 12 Analogue reading per second through the ADC.