TCP/IP communication between CVI and Arduino

[Kowalski43]

Hi there,

i´m trying to communicate between CVI running on my laptop and an Arduino Nano RP2040 Connect via TCP. The Arduino acts as the server whereas CVI registers as a client. Establishing the connection works fine, however i`m only able to send data from CVI to the Arduino, not vis versa. In the attached example i´m sending a request from CVI to the Arduino which arrives properly as can be seen in the attached screenshot from the Arduino´s Serial Monitor. Then the Arduino replies which should trigger the clients Callback- function right? Unfortunately this is not the case. Do you have any ideas how to fix this issue, did i forget something crucial?

Note: i´m using CVI 2009 with "tcpsupp.h" and i´ve tried running cvi as a server and register the Arduino as a client before, that didn´t work either.

Thanks for your support, Kowalski

[RobertoBozzolo]

Hello, your program is stuck into getchar (), I don't think the callback will be fired in this case even if the Arduino answers the query.

Try implementing the standard paradigm with a panel and RunUserInterface () so that your app is processing events.

[Kowalski43]

Thanks for the quick repsonse, using a panel and RunUserInterface() did indeed work.

Unfortunately i´m still not able to register the Arduino as a client if CVI is acting as the server. I´ve used CVI´s example "server.cws" located at ...\CVI2009\samples}tcp\server.cws which implements the standard paradigm so i guess there should be another problem.

In this example the user can enter a port number (i used 50000) and the program registers a server at the entered port. I´ve attached the examples code, the sketch running on my Arduino trying to connect to the server as well as a screenshot of the Arduino´s serial monitor.

Do you have an idea what could cause this problem?

Appreciating your help

Kowalski

[RobertoBozzolo]

Could it be that your firewall is blocking access to the PC? Try suspending the firewall for a few minutes and test the connection.

I cannot comment Arduino code since I know nothing of what's running on that platform.

[rolfk]

The Firewall is definitely a good suspicion. Most firewalls work in the way that you have a permission per application that defines if the application even may use network sockets. That is often presented in a dialog box when you start the application for the first time and it tries to open its first socket. Most firewalls remember the setting the user entered at that moment and this dialog is very easy to click away as "yet another annoying" installation/startup dialog.

The nasty thing about this firewall is that it does not cause the network functions to return an error. Instead it allows the app to open as many sockets as it likes but simply connects them to a big black hole. Anything send out wanders into nirwana, and nothing ever comes in. This is to not teach the potential malware that something is actively blocking it.

If your app has been granted the right to open sockets you can send out data and receive data. But there is often another security in the firewall. When you establish a client connection from your computer to another device you are creating a so called outgoing connection. Most firewalls will allow such connections once the application trying to create it is cleared. And data packages from the remote side will simply be left through too, since you initiated the connection and the firewall assumes that you know what you are doing and don't try to connect to malicious servers.

But if you create a server (listener) things are very different. Now the connection originates from outside of your computer. Many firewalls will not allow such connections by default since they could be malicious. You then have to add specific rules to the firewall that allow incoming connections on a specific port number or a range of port numbers and depending on the firewall also per protocol (UDP, TCP, or for high end firewalls with stateful package inspection even more specific protocols such as only HTTP, or SFTP or similar).

Disabling the firewall altogether is a first debug step to see if it is the cause of your problem but of course not a solution. Computers without a firewall and a direct connection to internet are nowadays under attack within minutes of being connected.