Nano as client LabView as server

[acxysty]

Dear all
We are trying to run an application where Nano will be a client and a PC/Labview will be a server under TCP/IP MOBDUS protocole.

We are facing the following situation:
Nano adress the right frames at the PC (adresss:502) and the PC reads them OK. PC return is right adress of the Nano but a un-expected port number (57266). Our understanding is that this is the port used by the Nano to send the data and it becomes also the port towards which the PC want to send the respond frame. This port is not 502 but this may be OK as Nano is client ?
How can we read the 57266 port ?
Regards
Thietrry

[support]

There is normally not necessary for you to manage the port specifically. The server port on the PC is 502. The Nano-10 will use a random out going port number to connect to port 502 on the server. Once connection is established both side will know the port number of each other and will communicate using that specific port until the connection is closed.

Is your PC setup to use Modbus/TCP instead of Modbus encapsulated TCP? Nano-10 can only communicate using Modbus/TCP and not encapsulated protocol.

[acxysty]

Hi

Thank you for your quick feedback.

According to your explanation, when client Nano will be able to read  frames on the 57XXX port when the TCP link is established ? we will test that this morning !!  Just for my understanding, reading on COMM4 is not only made on port 502 ?

We have tested the reverse configuration : PC client / Nano server and it works fine so the protocole is OK.

Regards

Thierry

[acxysty]

Good morning !!

It looks like it works from Nano to PC and from PC back to Nano but we have no change of STATUS(2). Status(3) changes according to the TCP connection.

We have monitored the frames in both direction with Wireshark and we are sure that the frames are OK.

We have change setsystem 1, 128 to keep the port open for a 20seconds but it makes no difference.

So our question is : what status(2) is checking ? and why it does not change state when an appropriate response is sent by PC ?

We have done the same experiment between Nano and FMD and it works great with Status(2) and Status(3) doing what we expect !!

Regards

Thierry

[support]

STATUS(2) and STATUS(3) only work when the PLC is opening a client connection to another remote server (such as a PC). This is to enable the application program to know if it is still connected to other servers and can take appropriate actions.

When the PC client is connected to the PLC (as server), STATUS(2) and STATUS(3) have no effect. The PLC server connection from a PC client is completely transparent to the PLC application program. That's just the way it is supposed to work.

Remember that the PLC can accept up to 6 incoming connection. There is no simple way for the PLC to express which connection is still active via a STATUS(3) command.

In future firmware we may implement a special STATUS command to show which incoming connection is still active. But this is not yet available for current firmware. You are welcome to send us suggestions that we could incorporate for future firmware releases.

[acxysty]

Dear Support

Thank you for your feedback.

We understand that statuts(2) and (3) are for PLC working as a client.

After many hours of testing we could not get the Statut (2) going to 1....

Let me sum up the situation :

PLC(FMD) is client , PC/labview is server.
PLC open the connection OK
PLC send the modbus/TCP frame OK
PC/labview read the frame OK and do the job
PC/labview built the returm frame and sent it to PLC (seen by wireshark). We believe that the frame is OK because we can retrieve all the MODBUS protocole.
But STATUT(2) remains to 0!!

The same with 2 PLC (Nano and FMD) works ok.
One difference is the time to do the whole operation :
it takes over 5 sec in PLC/PC situation and a couple of 100 ms with PLC/PLC.

So we use SETSYSTEM 1, 100 in order to have a longer waiting delay (15sec) but it makes no changes. Is this acting on MODBUS/TCP ?

Any suggestion where to look at ?


Regards

Thierry

[support]

The SETSYSTEM 1,n only works on serial protocol and doesn't work on the Modbus/TCP.

We do not expect the Ethernet communication to take so long. How come it is taking 5 seconds to get a response from the Labview server? It doesn't sound right and certainly quite unusable if the PLC has to wait for 5 seconds for a response from a server (while waiting the PLC will not run the ladder program which means all input will not trigger anything during the wait). It would have considered not getting a response from the server and therefore will not set status(1).

If for whatever reason the Labview server does need up to 5 seconds to send a response,  then the Nano-10 will not be able to read data from the PC, but still can write data to the PC - it just won't set the STATUS(2) since it will think that the communication has failed but labview will likely to still receive the data.

[acxysty]

Thank you. This is a very valuable answer.

I fully agree with your comments regarding the PC/Labview time scale : it is not acceptable and we are going to investigate on this point.

Because of this long delay we introduced a long delay (10 sec) before closing the TCP connection between PLC and PC. But this did not help regarding the change the STATUS(2).

This mean that STATUS(2) remain avaliable for a change for a short time after the WRITEMOBUS command. Have you any idea of this 'opening time' ?

Best regards

Thierry

[support]

Actually when I said you can use WRITEMODBUS to write to the PC it doesn't mean that the PLC would think that it has successfully written the data. In fact because the PLC did not receive the timely response from the PC server it consider the write to have failed and therefore STATUS(2) is set to 0 all the time.  And by default the PLC will retry another two times to send WRITEMODBUS command since it failed to get the response in time.

However, the PC server may still receive the write from the PLC (it just didn't respond).

Note that SETSYSTEM 1,n actually works on COMM4 for Nano-10, but only support maximum of up to 3 x 0.15s wait time for each COMM channel 1 to 4:

SETSYSTEM 1,n

where n = WAIT CYCLES  xx xx xx xx  two bits per comm port

    bit 0 & 1 for comm 1  
    bit 2 & 3 for comm 2  
    bit 4 & 5 for comm 3                  
    bit 6 & 7 for comm 4  

00 = wait 0.15s for response
01 = wait 0.30s for response
10 = wait 0.45s for response
11 = wait 0.6s for response

So if you want to extend the wait time for READMODBUS via COMM4, run SETSYSTEM 1, &HC0 and the wait time will be extended to 0.6s which is the maximum supported wait time.

[acxysty]

Thank you Support for this information.

We will test that and report to you.

Regards

Thierry