Step 7 Communication between Libnodave and WinAC RTX

Jornn

Level-1
Beiträge
1
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
Hello,

First of all, sorry for writing in english but I don't speak German very well. I hope this isn't to big of an issue.

I'm currently doing an intership and they have a problem with the communication between Libnodave and WinAC RTX.
Libnodave was working fine with the IBHSoftec PLC, but isn't working correctly with the WinAC RTX Softplc.
They are currently using Libnodave, and want to keep using it. However, they want to change from an IBHSoftec softPLC to WinAC RTX softPLC's.

So my assignment is to get Libnodave communicate with WinAC RTX. Unfortunately, I am not the best java programmer, nor do I have a lot of knowledge of PLC's, but hey, that's why I am doing an intership.

I am using:
- WinAC RTX SoftPLC
- Libnodave-java-0.1

After going through the code I noticed that when the program enters testReadReult() in the class PDU, it tries to read mem[param] and compares this with FUNC_READ which is 4. Since param = 17, I tried looking at what the current value of mem[17] is, which is 1. The function returns RESULT_UNEXPECTED_FUNC, which is -128, back to the function readBytes() and this is where it goes wrong. Since the returned value -128, which is saved as res in the function readBytes, is now being compared with RESULT_OK, which is 0 and then the program ends.

I am guessing something is going wrong when the program is reading out the header bytes of the datablock.

At the moment I am not sure what to search for, or where to search. So if anyone has any hints or tips those would be greatly appreciated!

Thanks for any replies!
 
Zuletzt bearbeitet:
Hi,
the main problem with the java version of libnodave is, that is hasn't seen any of the updates and bugfixes that the C library of libnodave has, for the last 10 years.

So it's possible that there are other unfixed bugs.

The communication the WinAC RTX fails, because the java version of libnodave doesn't handle the TPKT/ISO packets correctly.
A special thing with all Siemens PC versions is, that they send a so called "fast ack" option for S7 communication.

The response telegram from this partner sends at first a TCP packet including a TPKT/ISO packet of minimum size (7 bytes overall) where the "Last data unit" flag in the ISO part is not set. After this another TCP packet follows (or possible in a single TCP telegram), with the S7 data and set "Last data unit" flag in the ISO part.
As a simple solution, the driver should check the "Last data unit" flag, and read from the TCP socket as long as this is flag not set, and reassemble that payload of the TPKT/ISO stack. This is what you have to fix if you want to use the java version of libnodave.
 
Zurück
Oben