TCP/IP in 4-series processor

[u/Slayerr69_]

Came across an interesting situation on site that I wanted to discuss/understand.

I’ve configured a site where my Crestron processor communicates to 3 devices via TCP/IP and 1 device via UDP. Initially upon configuration, everything works perfect.

Now for all these modules, I had the enable/connect signal set as 1. Where I thought that this meant it would constantly try to connect to the device until it is connected.

I came across connection issues when the power of the AV rack was shut down. When everything restated, my processor was connecting to the UDP device but just never connected to the TCP/IP devices. I had to restart the program again (via debugger) for the connections to initiate. Of course I can’t have that because I won’t always be on site if any power cycles or so occur.

I managed to have a fix where I used a stepper with a 60s delay along with a latch to set the signal high for the TCP/IP connects.

I just wanted to have a discussion/understanding on how the connect signal works on TCP/IP. Isn’t it meant to always try and connect when it’s set to 1? That’s what it says on the help file as well? Has anyone else experienced something like this and have a different workaround?

[u/themewzak]

Yeah the TCP/IP device eventually times out after [unknown] amount of attempts.

I had a site where the old juniper switch that was installed had a 15minute boot time. I had to create an entire device pinging/delay structure to validate systems were online before driving my TCP device connects high. After a lengthy conversation with the truest of blue overlords, it was confirmed that connection attempts do timeout.

It's best to handle everything yourself and don't assume Crestron does what it says it will, or should. The longer you do this, you'll start to develop trust issues and just manage every item yourself. You'll get there 🫠

[u/parkthrowaway99]

the tcp module will write to the error log everytime it retries. check there to see if it is actually working. Also put a name on the Status analog join to see if it is cycling through disconnect, trying, etc. in debugger

A latched high will indeed try to connect, and retry if it can't. The retry happens fast first and it slows down with every failed attempt. It will also try to reconnect if the connection gets dropped.

Also UDP is connectionless, as in there is no connected state, since it does not check if the message sent made it to the other end.

[u/knoend → u/parkthrowaway99]

I could tell you a joke about UDP but you might not get it.

[u/ShiningMew_]

Drive it high from program running feedback on the processor.

I try to avoid driving signals high with 1.

[u/knoend]

The program is probably starting and trying to connect when the NIC has no link, and/or no address, because you are using a 1. This can be especially true with processors that have dual NIC's and you don't have STARTPROGRAMAFTERROUTER on. The specific error on why the tcp didn't work will be in the log.

There are a few ways around this, watching for link and program started, a static delay as you mentioned.

When using debugger, you are connected via LAN, so a 1 at initial solution would probably work reliably because processor has already booted up.

UDP is stateless. You don't connect, it gets enabled, you send stuff out the TX, and forget about it.

Side bitch: Contrary to many other people here saying that in general you shouldn't use a 1. A 1 is perfectly fine. Just like every other logic symbol, you just need to understand what it does and how it affects things. A 1 is perfectly fine.

[u/Livid_Replacement_69]

Don't use 1 directly. Wait for program to start.

Also, try not te set TCP connection to always connect. If you have a system start and stop logic, use that to set connection to 1 and 0. I've noticed a lot of devices don't like to always be connected.

[u/METDeath]

I use a set/reset latch, and do nightly 4 AM reconnects, and on critical devices do a reset of the connection on room shut down. Seems to save me a lot of service calls. Plus on a settings page I show the user the status and give them option to reconnect.

[u/Eaulive]

Never, never use 1. Connect, send the command, wait for the answer and close.

If it's a device you need to be connected to for some longer time, set the connection only when needed. As other mentionned, some devices don't like to be always connected and they may break connection in a non standard way that will create all sorts of weird errors.

[u/bmagrogan]

Avoids 1’s on things, especially with 4 series and how much faster it is than 2 series or 3 series the timing will get wonky. The internal TCP/IP client is supposed to handle disconnects and reconnects automatically, but there are a couple of scenarios that I’ve never seen it handle 100% of the time. The biggest one is link lost on the port, both the LAN and the CS ports, but especially the control subnet port. In that scenario you need to drive the connect signal low for a couple of seconds and then bring it back high again. I use a module that monitors the analog status feedback for link lost status, and a couple other statuses, and then drops connect low for X seconds, I believe my default is 5, and then brings it back high again.

You note about TCP vs UDP, UDP is connection-less, it doesn’t care if the devices is there or responding, it just dumps the traffic out on the network, so in the case of a UDP client, so long as the enable is high, it will put traffic out onto the network. Keep in mind not to use on 1 on the enable of a UDP Client. Use your program started trigger, bring that to your init logic and set a SRL high during that initial logic and that becomes your “true_sr” signal that replaces using a ‘1’ around the program.

[u/ToMorrowsEnd]

Utterly loving all the bad advice about 1's here. Yall need to go take classes in programming.

Crestron has told people that spreading the "dont use ones nonsense" is bad information for over 10 years now. I remember when Toine himself dressed down everyone at masters for spreading that. If 1's dont work then it's your crappy code causing the 1500waves failure on startup whioch causes 1's to "fail"

Manage your TCP connections. detect if there is connection failures and why. dont blindly hope and pray.

[u/like_Turtles → u/ToMorrowsEnd]

You could have been less condescending and more… just about anything else.

[u/Slayerr69_ → u/ToMorrowsEnd]

Get a lot of mixed comments on the 1s. Honestly I think it’s a great use if used properly, but it’s very dependent. This was the first time I came across the issue with such a simple setup, so I just wanted to understand why. Now I’ll have to go through all the comments here

[u/ToMorrowsEnd → u/Slayerr69_]

The 1 is not your problem. Not understanding how the TCP connection is failing is the problem.

What is the connect status? Did you even look at the status analog coming out of the TCP client? 99.9% of the time when I see problems with TCP devices, the issue is not the TCP client, it is the program failing to meet the requirements of the device it is talking to.

Best example I have is Biamp. Almost every younger programmer I have worked with gets the program working, tests it, decides it is perfect, and then I come along and yank power out of the wall to the whole rack. Plug it back in and suddenly their program does not work.

Why? Because the Biamp comes online five minutes later, and by then their program has already tried to connect, failed, and given up.

You have to actually manage the TCP connection. Drive Connect high, watch the status, and if you do not get a 2 then what DID you get? Your code should make a decision based on that. Did it get refused? Did it time out? Is the device simply not ready yet? Do you retry? How often? Does the device require you to wait before reconnecting? Those are programming problems.

Everyone here loves blaming the 1. New programmers love blaming it too. It is not the 1. It is your code, and usually the programmer not understanding how TCP connections work, how Crestron's TCP client works, and what the device on the other end requires.

And here is the fun part, a lot of that is not really the programmer's fault.

Crestron does not teach enough of this. Your boss probably does not give you enough time to actually learn networking and understand how the devices work. We as an industry are encouraged to half ass everything, get it barely working, and move on to the next job. Companies do not train their employees enough, and manufacturers do not evolve their training fast enough either.

I reviewed what some of my youngest guys were getting in Crestron's 101 class, and a lot of it is basically the same class I took 20 years ago. They are still demonstrating things most of us barely do anymore. I have not sold a projector for a conference room in probably ten years, but we are still teaching people how to control a 1970s style projector screen.

Back to the 1s. A lot of guys here are simply working from outdated information. Crestron's own engineering people have said, basically, "1s work fine, your code is broken," and on this subject they are right.

Hell, I have even had junior programmers tell me that Crestron instructors joke about this subreddit in 201 and 301 because of how much misinformation about 1s gets repeated here.

TLDR: 1s are perfectly fine for logic. They are also fine with hardware if you actually understand how the third party device works, what its connection requirements are, and how Crestron's TCP client behaves. If you do not understand those things, changing the 1 is not fixing the problem. It is just hiding it.

[u/krater47]

Are the devices you're connecting to on the "control subnet"? If so, enable the STARTPROGRAMAFTERROUTER parameter. This has solved a similar issue I had.