Keyboard Shortcuts
Likes
Search
TCP Client Stopped working
|
Hi All,
Wondering if others have seen this odd, intermittent behavior...and also a heads-up for others to watch out for it CP4 (v2.7000.00040) has a TCP client communicating with a Vantage System (though I don't think the remote device matters). It was working two weeks ago, and we checked yesterday (client is out of town) and found that it was 'Not Connected' and specifically not trying to Re-Connect. The Status analog just stayed at '1d' instead of the typical toggling between 1d and 3d (Waiting for connect vs Connect Failed) As I have a '1' on the Connect input, I could not test if toggling this would fix the issue, Rebooting the Vantage processor did not restore. Only restarting the program slot restored the connection. I spoke with Crestron TS to trouble-shoot this, as I've never seen this behavior before, and they have confirmed that they have seen this a few times, offering: 1. They said it was 4-series issue, spanning fw updates 2. Use an S+ emulation module of the TCP client until they fix the issue...:( Clearly this is a specifically intermittent issue, as I have not seen anyone else talking about this lately, but they have confirmed that there is a problem.... In a related note, another friend of mine who I trust with his technical knowledge and experience, says that he has seen this issue? for years on both 3 and 4-series systems. He feels that it is a long-standing issue that has not been dealt with and thus probably will not be fixed... Given my experiences over the last 5+ years with TB, I would tend to agree. To have to use a custom S+ module to handle this is absolutely ridiculous - the TCP Client is a native hardware device symbol... What experiences have other had about this?? |
开云体育I’ve seen an issue on my home system (PRO4) a couple times but not with enough frequency to get enough info for a proper bug report where if the Ethernet link is lost under some circumstances the connection will not retry until the program is reset. The status in the IPT is “LINK LOST” – but this doesn’t happen on every link loss event. (Most recently I saw it because I was upgrading one of the edge switches in my AV equipment room) ? The other thing to remember is that the TCP client retry time rises exponentially the longer it can’t connect to the other device, e.g. the longer a device is off line the longer it will be between retrying the connection (I want to say the upper end is 65000 seconds but I’ve never personally tried it) so if the device had been offline for “a long time” that could explain why it didn’t seem to be retrying. ? Beyond those two cases though I can’t say I’ve seen any systematic issues with the TCP/IP client on the 3- or 4- series…. And I have a few applications where I know I’d know if there were issues because the failure would be critically obvious. ? ? -- Lincoln King-Cliby, CTS, DMC-E-4K/T/D ? From: [email protected] [mailto:[email protected]]
On Behalf Of ckangis
Sent: Saturday, April 09, 2022 11:22 AM To: [email protected] Subject: [crestron] TCP Client Stopped working ? Hi All, |
|
I never use "1" on a TCPIP client module, I always use a connection manager to connect to the device when needed and close the connection after. This can be as short as a few milliseconds to send a command and acknlowledge the answer or as long as the system or page is in used, but never 1.
I never had any problems this way. At least disconnect from the device when it's not in use is a good idea. |
|
Olivier,
Yeah, I'm not sure why I have a '1' on it (probably some legacy thinking...) at minimum, I usually make it an actual signal, that is driven by a '1', thru a buffer, so that I can at least toggle it in Debugger... I like the concept of your approach, though I find that more often that not, you want the comm's running all the time for status updates (unless its a 1-way control). This in particular is a lighting system so there's alot that I want to have ready to go without having to poll and wait. FTR, I almost never turn the connect off with any device and have not had any particular issues until now... This is a *Problem* with Crestron and their TCP client...hopefully we'll see a fix soon... |
开云体育?FTR, I almost never turn the connect off with any device and have not had any particular issues until now...“ ? Same here. Especially in my home/test-system, i?ve got a lot of TCP Clients in the program pointing to devices that are rarely switched on or connected because i just need them for some specific testing. Never had a problem that the TCP Client wouldn?t connect after the device is connected or switched on. Actually, i?m assuming more issues with permanently activating and deactivtating the TCP Client, but it sounds as if that?s working reliably. So i think i?ll give it a try. ? Cheers, Thorsten ? Von: [email protected] <[email protected]> Im Auftrag von ckangis ? Olivier, |
|
I've seen this since the very first CP4N we installed right after they came out, and your experience sounds a lot like mine. In S+, you can leave it to stay connected and automatically reconnect and it'll work, but a TCP Client symbol gets stuck waiting. Restarting the program is enough to get it working again. I've tried various catch-and-recover methods that seem to have worked, but I've been trying to make or use S+ or S# modules to handle TCP stuff anyway so I notice the issue less and less as a result. It's definitely not just you it's happening to!
|
|
I've seen this as well. I have a case open with TB right now for it. What I was able to narrow it down to was if you lose link on the CS side of the processor that is what breaks the TCP/IP client. I was able to reproduce it everytime that way. I wrote 2 dummy demo programs and sent it in, one with a TCP Client and another with a TCP Server and took a video of it failing and a software reset/hardware reset fixing it.
I've never seen this on a 3 Series, only 4 Series, but I can certianly adapt my program to test it over on a 3 series as well. At home I have devices on CS that I'm using a TCP Client for communication and after switch reboots, switch firmware upgrades, power cycles, etc I've never found the devices to not properly reconnect. I just checked my case and no updates since April 1st when they said they would mock up my programs and get back to me. |
|
Thanks, Jonathan, Brian and All,
It definitely seems like a highly intermittent issue, might even be a one-off sometimes. I'll be connecting into the site that I've had this issue with and will see if the connection has failed again (been since Friday afternoon). I also have a case relating to this so we will see... Jonathan: It would seen that this has been an issue since the beginning of 4-series... Because of the '1' on the connect input (I'm changing this now) I can't try to restart on this project. Have either of you found that a toggle on the Connect fixes the issue, or does it always require a program restart?? FWIW, I set up a simple TCP client test on both CP3 and CP4 with nothing to connect to them so that they would just keep trying to connect, basically testing if the symbol would give up after a while, and both are still humming along since Friday afternoon. Both still toggle between Waiting and Failed, as expected.? The CP3 client waits a bit longer than the CP4 (20s vs 3s) but both stay on failed for just over 1 min then back to Waiting. On my Vantage site, the TCP client just stayed on WAITING... |
|
Chris,
I don't know if they are related at all, but ... I have still been having issues with EISC connections between 3 and 4 series processors. That is with the 2.7000.00040 firmware installed on the 4-series processor, which was supposed to fix the problem. Just last week, I updated a site to the 2.7000.00052 firmware hoping that would be a permanent fix. It is completely random and definitely a 4-series problem. About once every month or two I have to reboot a CP4 running a D3 program.? It shows connected in the IPT but the CP3 doesn't. If Crestron can't get its own EISCs connecting reliably, that has me concerned with all other ethernet communication. Fun times! Brian |
|
I'm curious what the results were to your testing. ?I'm having a somewhat similar issue with a HTTP GET that is used for polling. ?I've been running on CP3 with both 1.6 and 1.8 FW and had the same results. ?If you look at the NETSTAT command you see sockets ESTABLISHED, WAITING, etc. ?The start port seems to be around 48xxx and when the counter gets to about 59xxx there are no more ports. ?I would thing the garbage collector in the OS would recycle these ports but no love. ?Ive seen this happen with S+ direct connections and S# GET with identical results. ?The only fix seems to be rebooting the proc :( ?I'm doing the same stress testing on a PRO4 and the start port is around 12xxx so the testing is taking quite a bit longer.
any ideas? |
|
hi Michael,
I think my situation is different than what you're dealing with... I just had a TCP client stop communicating and would not keep trying to re-connect. Since rebooting the processor, we haven't had any issues (??). It was suggested that I set up a routine that periodically tests the connection and toggle the 'CONNECT' input if things are down for X time. I haven't gotten to this as I don't have regular connection to this site.? I assume that if I changed to a websocket, this would also 'solve' the potential issues... Alternatively, It'd be great for Crestron to fix this kind of thing - In 20+ years of using TCP clients I've not had this issue personally, so it is very unusual I think... |
|
This is a related problem, but not the same... however I think this solution may work for 4 series too. In a 3-series I have the same "Link Lost" problem with the communication with a HomeworksQS system. We install this kind of configuration in almost all of our projects and never happened to us before. What other behaviours I notice are:
1. After uploading program it works fine. 2. If I reboot the system, the Link Lost appears and the communication can't be reestablished until I upload program again. 3. If I connect to the CP3N just before the program starts, when it does the connection is successful and about the time some touch panels reports themselves in the console, I got the Link Lost. 4. We have a very similar problem with CP4N, but in that case, we can reboot the system and it works. 5. It works flawlessly in a 2-series. So, the workaround I found is to wait 60s to establish the communication after the reboot. What I think is happening (at least in the 3-series) is that the system does some initial tasks with the TCP stack that breaks this older kind of connections, so the idea is to wait until everything is done and then connect the third party system. I use a simple delay in Simpl, between the signal that establish the communication and the TCP Client. Try that with your 4 series system, and let us know if it works. clemare |
|
Since this topic is being resurrected I’d love to know people’s general thoughts on whether or not the TCP Client, along with other IP issues, has been fixed on 4-series yet. I still have several issues with: |
|
Other than the one instance/site that I had the issue with, that started this thread I haven't had any real issues with TCP client connections. Things have been very stable on 3 and 4-series...
Note: By default, I start my TCP connections programmatically (i.e. with signal triggers not a '1') after the main program is fully started. This may contribute to more stability, though I do it only for my own feeling of wanting to stage things in an orderly manor, not because I actually found it to be required (though it may actually be...) |
开云体育Same here: no issues with TCP Clients. Also on 3 and 4-Series and also a mixture of “1” and enabling programmatically. ? Cheers, Thorsten ? Von: [email protected] <[email protected]> Im Auftrag von ckangis ? Other than the one instance/site that I had the issue with, that started this thread I haven't had any real issues with TCP client connections. Things have been very stable on 3 and 4-series... |
|
I've definitely had issues with TCP/IP Clients not reconnecting on a CP4N the way they would on 3-series, and even worse not disconnecting and reconnecting when the Connect line is dropped and raised again.? My current working logic is to send a ping command every 30 seconds, and if it goes more than 10 seconds without a response, drop the Connect line for 5 seconds.? When it only dropped for 1 second it wouldn't reliably reconnect to the TesiraForte or Shure MXA920s.? Current firmware on everything. On Sat, Apr 13, 2024 at 7:31?AM rickwookie <rickwookie@...> wrote:
|
|
I made a decision a few years ago (6+ ?) not to use the 'N' models (CPxN, Pro3/4, AV3/4) because of the extra 'special sauce' that they had to manage/maintain. I felt that this possibly created issues that the standard processors without the router did not.
And I have not secret knowledge that that is the route of your problems with the TCP functions, just a gut that there's too much going on with the 'N' units. NOTE: my initial problem was with a CP4 not an 'N' unit. I also understand that you probably have to use the 'N' units particularly in commercial settings. I play primarily in the hi-end Resi world where we can (and demand!) that we control/manage the network so I don't have to use those processors... If you can stay away from them and manage your network needs via a 'real' router, I would do that. |
Michael Block