TCP read and TCP write work separately but not together/ ESP32 connection

[mariamariablue888]

Hello,

Here is a VI implementing a TCP protocol with the ESP32.

I can get an LED to turn on and off using TCP write.

I can get a temperature reading from the Thermistor using TCP read.

But when I put them both together in the VI, it doesn't work.

The LED is not working or works slowly.

I am not sure how to get both connections to work simultaneously.

Thank you.

[tst]

The description for how it doesn't work is not very clear and I don't know the APIs in the microcontroller, so hopefully these comments can help:

1. First of all, debug. Uncomment the relevant lines in the ESP. Add probes or indicators on the LV side. See what's actually happening. That's the thing that's most likely to help you solve this.
2. You're reading 8 bytes and have an infinite timeout on the TCP read. I don't know how that relates to the print function and the CRLF you're sending.
3. You seem to be waiting for serial data on the ESP side before reading the temperature. Is the temperature coming in as serial data?

My guess would be that you're sending fewer than 8 bytes and then the TCP read waits for more data which will only come after you send to the ESP through the serial terminal.

[mariamariablue888]

Hi,

Thank you.

The TCP read part works great by itself. I attached a screenshot of that below.

This is functioning. The data is coming in through TCP. And, yes, I write something in the serial port, and it starts reading the temp.

The button by itself is also functioning when programmed below with the same C++ code:

The problem happens when I put them both together. The button does not work with the LED anymore.

I will try to probe/ add indicators, as you said.

I am trying to understand how the TCP read/TCP write functions affect each other.

[tst]

There seem to be a couple of difference between this code and the previous one:

1. The somewhat minor one is that you don't have the timeout input on the TCP read connected, which I believe defaults to a timeout of 25 seconds.
2. The much bigger one is that the mode input has a different value (standard as opposed to CRLF). The CRLF mode causes the read to end as soon as a CRLF arrives, which means that your read ends even if you didn't get the 8 bytes you requested.

To be clear, the read and write parts don't directly affect each other here (unless the write would generate an error which would prevent the read from running), but because they are in the same loop, both have to complete before the next iteration of the loop can run (and if you don't get 8 bytes, the read will be stuck waiting for them, which is probably what happens).

[mariamariablue888]

Ok thank you. This helps in understanding better how the read and write work.
I will try different settings for the read and see if this is affecting the loop.