Interesting IP communication
Irvine_Kyle
Posts: 67
Just a quick note here. I was at a job the other day tryin to get an ESCIENT fireball comunicating over ethernet. The problem had been that things would be communicating just fine and some sort of interenal hiccup with the ESCIENT would effectively kill the socket we were using. The problem was that AMX had no way of knowing whether or not the socket was still communicating with the device. So a friend of mine and I were tasked to write some code that would ensure that we always had good comunication. After several permutations we finally got some code writen that would ceck for COMMS every 10 seconds or so and with no reply would close the socket, wait for the offline event to occur, then reopen the socket. We noticed that even with the ESCIENT physicaly unplugged that NetLinx would still open the socket, there was infact no way to tell wether or not the socket was actually communicating to the device. It's a little early in the morning for me to explain all this, but I just wanted to see what other AMX programmers do to ensure that they have good comms over ethernet to a device. Any thoughts?
0
Comments
If the NetLinx is a SERVER, I hold the socket open for only x seconds after I have received any data. If I receive data within that time, the timer is set back and the timeout is starting again. If this time is over, I'll close the socket, wait for some seconds and reopen the socket.
As a CLIENT, if I got an ONLINE previously, I try to send a command to the server. If I don't get any reaction for x seconds, I'll resend the command again. If I still don't get any response again for x seconds, I terminate the socket, wait for a few seconds and try to reopen.
But this also depends on the protocol and socket handling of the remote device, so this is only "in general". :-)
Anyway, the bottom line seems to be a NetLinx master does not reliably detect a dropped TCP connection. This can really make hash of trickily synchronized protocols, and my tendency has been to use RS-232 when I have a choice instead.
I do quite a bit of TCP/IP communication from a client perspective including native TCP devices like the Escient Fireballs and other serial devices like Lutron, Denon, and others using a serial-TCP converter. In general, I open the client connection, wait for the ONLINE event, mark the device as READY, and then I hold open the socket. I also monitor the OFFLINE event for a dropped connection at which point I will re-connect but like Marc and Dave pointed out, there are times where the connection is dropped without an OFFLINE event. I also use a TIMELINE event to issue keepalive protocol requests to the device and I await its response to keep the device marked as READY. If I fail to get a response from a keepalive request, I close the socket, re-open it, and start the process again. This works well for me across a broad range of devices. The Escient's are quite reliable (except for the E2 software upgrade - see below) and the serial-TCP converter I use is extremely reliable so this explains my success rate.
Regarding Escient, with their Fireball E-40, E-120, and DVDM-100 products, they were very well behaved and would support a client connecting to them for long periods of time without any problems. With the introduction of the new E2 product line, in particular the first E2 product known as the E2-300, they use a different core OS version. This version, for some reason, closes its server TCP connections every 60 minutes. There is no way to change the timeout or turn it off. I reported the 'problem' to Escient, they confirmed, and frankly they do not seem to be that interested in it. Their advice was to 'code around it.' Escient is now in the process of offering E2 software upgrades for existing E-40 and E-120 owners and they will follow with the same for MP-100 and DVDM-100 owners. I recently upgraded an E-40 and E-120 to the E2 software base and the same 60-minute TCP server timeout is in the upgrade release. Therefore, as everyone migrates to the E2 base, they will see this behavior on their older Fireball products so Escient modules need to be coded accordingly if you want a long lived TCP connection to them.
Lastly, having encountered problems where Netlinx did not detect a dropped server connection properly, I checked with AMX TechSupport regarding support for TCP keepalive, TCP timeout, and other network level parameters that can affect how a client detects and reacts to dropped connections. TechSupport was going to issue an RFI to engineering to get a response as to how Netlinx interacted with VxWorks to handle TCP level connections (in particular dropped connections). I have not heard back from them regarding any information on TCP handling. With TCP communication becoming more popular and with more devices offering native TCP support (Lutron P5 processors, Denon 5805, ...), the trend will ultimately be toward using TCP for a broader range of devices. I was hoping to have seen something from AMX in the form of a Tech Note - perhaps we will at some point in the future.
I have had good luck in general with TCP and where possible I use it. You do have to make sure to have robust connection handling and some type of keepalive mechanism in order to reliably use TCP.
Thanks for this post. I have about 3 E-40's out there schelduled for updates 'when I have time'. I would have been scratching my head as I don't even look for anything from them (just basic control commands)..
Thanks,
Kevin D.
Kevin,
Glad the information was useful. Fortunately, if you capture the Escient TCP server shutdown in your Netlinx OFFLINE handler and then re-open the connection to the Escient device, the Escient readily accepts the new connection and keeps it open for another 60 minutes. I just find it an unnecessary annoyance. I would not mind so much if Escient provided a configuration option to turn off the behavior, but no such option exists. Netlinx does however reliably detect the loss of the Escient connection so we can indeed program around the problem (or feature as some call it).
One other thing, although this is off-topic, the E2 upgrade provides a new button overlay feature that can be used for installations where you utilize X, Y control of the Escient through an external touchpanel. Unfortunately, they implemented the capability so that the overlay is only compatible with VGA displays. Therefore, if you try to utilize the S-Video output of an E2 Fireball product as the input to a TPI/4 card using S-Video, the overlay is only partially visible at the edges. The Escient solution is to always use VGA. We found this using an Extron S-video switcher which switched its output to a TPI/4 with S-video since the same output can be displayed to televisions or other non-touchpanel video devices.
Reese
As far as the overlay, that sucks.. While we haven't implemented it on a job that way, my home one utilizes the composite out on my AXT-CV. It's an H40 that can't handle the upgrade, but I was thinking of trading up to a E40 to get the upgrade.
On the upgrade.. worth it?? I don't think any of my customers would use the web-control portion, but I was wanting to upgrade them so they could actually send songs over to the server. It's kind of a pain to burn and then rip since some Windows update killed Escient's Pipeline about 2 years ago..
Kevin D.
Kevin,
Regarding the benefits of upgrading, I was very interested in the web interface since being able to control the device using a browser is great. I only wish (different thread on the AMX forums) that we had a web browser built into the Modero MVPs as this would allow native Escient control. Sounds like web control would not be a big selling feature for you.
The other major features in the upgrade are the Pipeline replacement capability as you noted and FLAC encoding. Given that Pipeline was a disaster for transferring music files, if you do this frequently then having the ability to drag and drop music files to/from Fireballs and PCs is a great benefit of the new release. I still think they have made cover art management much more difficult than need be particularly if someone only wants to update cover art for a title. I hope that the upgrade, when it is available on the DVDM-100, does not take away the ability to ftp or simply drag/drop cover art images to a directory that can be easily associated to a movie later. I suspect the upgrade is probably worth it for you.
Another TCP/IP related tidbit on the E2 upgrade, on a positive note, I did discover that the control protocol in E2 is at least a superset of the previous protocol since my current module was able to control the device just fine. They may have added some new protocol requests (have not found any yet) but they did not deprecate any in the upgrade process so your drivers should still work fine.
Reese