05-09-2023 08:51 PM
I have a code that reads humidity sensor information from an ESP32 and also sends information back in order to control some valves. Im using the TCP/IP protocol but I´m having trouble both reading and writing because I get the errors 56 and 66 randomly. I´m having a hard time understandig what the reasons for this errors are because in some places I´ve read that it is because it takes too long to read the data so it reports the error, but I have changed the timeout for the functions and the code becomes extremely slow. I have also read that it might be because the bytes to read may be wrong but I really don´t know for what number I could change it for. Or maybe it could be related to how I wrote the Arduino IDE code for the controller?
I was wondering if anyone could give me some advice about how I could fix this.
05-09-2023 10:53 PM
Make sure the IP address for the ESP32 is static, meaning it is not changing randomly. If the IP address is set to dynamic. When you reset your computer or system, there could be a chance that a new IP address may assigned to the ESP32. Make sure ESP32 is the only device using that IP address. Also if you use a different ESP32, a different IP address will be assigned to it, so make sure you change the IP address in your LabVIEW code accordingly.
Lastly, when you start running your LabVIEW code, make sure the controller (ESP32) is active, working. Turn ON your controller first, then run your LabVIEW code.
05-13-2023 07:35 PM
I tried all this and it kind o works now. It functions as it should for around 2 minutes, after that I get an error 66 in the TCP read function. I still don´t understand if this is caused by something wrong with my labview code or if it is because of the ESP32´s code.
05-14-2023 04:16 AM - edited 05-14-2023 04:18 AM
Error 66 means that the remote side decided to close the connection for whatever reason.
Possible reason could be:
1) your device has an internal timeout that disconnects after a certain time even if the connection was active.
2) It is configured to use dynamic address and when it refreshes its address it resets the whole TCP stack even if the address did’t really change.But a 2 minute DNS refresh cycle would be really extreme and might also point to a bad network configuration in your network.
3) Your device had an address conflict with another device in your network.
4) Your device is buggy.
05-14-2023 03:07 PM
I was actually testing the ESP32 with Hercules SETUP as client and it stays connected. So that would mean that the controller is fine and that the problem is in my LabVIEW code?
05-14-2023 09:22 PM
I´m trying to connect an ESP32 to LabVIEW to send and recieve data but after running for 2 minutes I get the error 66. I have tested my ESP32´s code with Hercules SETUP and I'm able to recieve and send information without the client disconnecting and the Arduino code works as it should so I have ruled out the controller and it´s code as the problem, so I createed a small LabVIEW test code to see if I can figure out the error. I started only using TCP open/read/close and it works fine. Then I added TCP write for one of the sensors and it also worked fine. But when I added a second TCP write, for the second sensor, it worked for 2 minutes and the I get error 66, the same way it happens with my main code. I tried using a -1 timeout to see if it helped but the same thing keeps happening. I´ve been watching many videos and tutorials and everyone seems to add the write function the same way that I´m doing it but it just doesn´t work for me. Any kind of help to figure this out would be very apreciated.
05-15-2023 08:38 AM - edited 05-15-2023 08:43 AM
With the simple program you posted there is nothing inherently poking out but there are several potential issues.
1) you use the TCP Read with CRLF mode. Does your server application really terminate its numbers with a CRLF character sequence? If not you will of course quickly run out of synchronization.
2) Are you sure your server application uses the same locale than your LabVIEW computer? Currently the "use system decimal point (T)" input on the Fract/Exp String to Number node is left unwired. This means LabVIEW will expect whatever your system considers a decimal point character (decimal comma for German and some other locales, decimal point for pretty much the rest of the world). If your server application is configured for a different locale, there might be a problem.
3) you return a single digit number as a result of a comparison. It is at least strange to expect the other side to send strings with a CRLF end indication but not send responses in the same format back. Without some form of synchronization (it could by also the fact that the server application always expects exactly 1 character as response but we can't know this), your communication channel rather sooner than later will get out of sync and that might mean that the server eventually decides "Enough is enough, you are providing only garbage as response that makes no sense. Goodbye!"
05-15-2023 04:38 PM
My server does send the values with the CRLF character sequence. I checked the locale and it´s not a problem. I was checking my Arduino IDE code and apparently the client.read function that i use only reads one byte at the time and also the TCP write function in LabvIEW is sending the information in ascii format so I think thats the problem but I have no clue of how to fix it.
05-15-2023 05:38 PM
I initially created a code using an Arduino UNO and Labview to send and recieve data and it worked perfectly. Now I need to replace the Arduino for an ESP32 and use the TCP/IP protocol instead of serial. I thought that I only had to replace the serial "reads and writes" with the TCP "reads and writes" but apparently it doesn´t work that way, at least for the TCP write which is seems to interfere with the whole code so nothing is working anymore. What I was supposed to do was send certain numbers, from 1 to 7, to Arduino IDE (the ESP32 controller), in order to turn some leds on or off, but when using the client.read() function in arduino and printing its result, and also from reading the description of the function, it seems like it only sends the number in ascii format, which seems to be causing my code to get error 66, since when i delete all of the TCP write functions everything works fine. Is there any way to get the TCP write function to work as if it were serial write? I´m finding it way too hard to just send some numbers without losing the connection between server and client and I ran out of ideas on how to fix this 😞
05-16-2023 04:40 PM - edited 05-16-2023 04:45 PM
The problem is not that TCP Write works fundamentally different than VISA Write. It doesn't!
The problem is that you are mixing ASCI and byte values. Apparently your ESP32 program expects a byte with the value 0 to 8 or similar. But you send in LabVIEW an ASCII character with the value '0' to '8'.
An ASCII character '0' has the byte value 0x30 or decimal 48.
So if you want to have a byte value of 0 (or 1 to 8 ) you need to send in LabVIEW a byte with that value.
There are several ways you could do that in LabVIEW.
First would be to enable \ code display in the string constant through the right click menu (and you should also make the glyph visible through the same menu). Then you can enter \00 in the string and it will send the byte value 0.
Or you could create an u8 integer with the correct value. Then use a build array to make an array of 1 integer element and then convert it to a string with Byte Array To String to connect to the TCP Write.
Or you could change the ESP32 side to not expect a byte value of 0 but 48 instead (49 for 1 and so on). I'm sure your ESP32 environment also has conversion functions where you can pass in your '0' ('1' to '8') value and it returns the byte value of that ASCII character.
For instance if you use C(++) on the ESP32 side you would compare the single byte you received with '1' instead of 1. '1' indicates in C that it is a single character '1' and the C compiler will convert it to the according ASCII byte value 49.