include "atlstr.h", compiler error

[Sakontanut]

Hi all ,

I have a question ,after adding #include <atlstr.h> in Opener program. I get many errors. I want to use Cstring. How to solve this issue? please could you guide me?

Thanks in advance,

Sakontanut

[Martin Melik-Merkumians]

Hi,

because ATL is C++, whereas OpENer is written in C and CMake makes sure that only a C compiler is used.

Best regards,

Martin

[Sakontanut]

Hi Martin,

Thanks for the answer. Problem solved but I still have other questions. I tried connect OpENer with PLC but I get error as following picture: please could you guide me?

Thanks in advance,

Sakontanut

[stm-at-esd]

Hi,

unfortunately that screenshot is not very meaningful. I would guess that error status won't change even if you completely disconnected (unplug) your device.

You should capture with wireshark a log of the network packets between the EtherNet/IP Master and your slave device. I believe this will give you some hints

what is going wrong (bad IP assignments or such things).

As a last resort you could post a wireshark log here taken from all devices off. Then power up your device and after that power up the EtherNet/IP Master PLC

in that order. So we could see if the devices even exchange any network packets.

Best regards,

    Stefan

[Sakontanut]

Hi Stefan, 

Thank you for your advice. I have tried what you suggested but the error still occurred. 

I think the network packet connection between the Ethernet/IP and my device shouldn't be problem. Including Register section. And then I found that the error is likely to occur in the Forward Open Request section. I think CheckForExistingConnection function Line 951 doesn't return the value of status correctly. Could you give me any advise. Sorry, I forgot to tell you that I just updated the version of Studio5000 and RSLinx Classic. I don't know if it will affect OpENer. Thank you very much.

best regards,

Sakontanut

[Martin Melik-Merkumians]

Hi Sakontanut,

I am not sure how the two screenshots relate in your opinion, but I guess you are refering to the Module Identity part which says matching.

A non-matching connection triad (this is what the forward open is checking) is something fundamentally different from matching module identites.

Without a Wireshark trace, to see why the connection is timing out (see your first screenshot), it is impossible to tell, why this is failing.

Also, if this part of the code is erroneous, which I currently don't see why it should be, you would get a different error message.

The implemented Forward Open service has worked without flaws for the last two ODVA PlugFests, so I would suggest to look somewhere different first for the error. I would guess this is either a config or network error.

Best regards,

Martin

[Sakontanut]

Hi,

Thanks for your advice. I have checked the IP network configuration. It does not seem to be a problem. Is there any other reason? I have stuck in ForwardOpenRequest and get error( non-null ,non-matching). Thank you very much.

best regards,

Sakontanut

[stm-at-esd]

Am Freitag, 8. Mai 2020 09:04:06 UTC+2 schrieb Sakontanut:

Hi,

Thanks for your advice. I have checked the IP network configuration. It does not seem to be a problem. Is there any other reason? I have stuck in ForwardOpenRequest and get error( non-null ,non-matching). Thank you very much.

best regards,

Sakontanut

 

Hi,

I've looked at the screen shots and it looks weird that the extended status in the Forward Open Error response is zero. I still recommend that you do a wireshark log including all packets since power on that are exchanged between the PLC and your device. If your log contains communication with other devices you can suppress these packets in wireshark and then only save the displayed packets in another log file that you then can attach to this discussion. This would help much more than these screen shots that contain far too little information.

Do you have changed the OpENer configuration regarding the assembly numbers (defines DEMO_APP_*_ASSEMBLY_NUM) or the IO sizes (size of g_assembly_data*)?

Best regards,

    Stefan

[Sakontanut]

Hi,

I think so, why status in Forward Open Error response is zero. But I have already attached wireshark file. Could you recommend what should I do? For OpENer configuration, I didn't change anythings and use original eds file. At first, I plan to test that OpENer can run without errors or no. After that I will try to modify the input, output and size. Thank you in advance

Best regards,

Sakontanut

[stm-at-esd]

Hi,

from the log I can see the following devices:

MAC IP Device

@00:00:bc:d1:ae:d5 192.168.1.10 Rockwell 1769-L36ERM/A (LOGIX5336ERM)

@08:00:27:da:03:d9 192.168.1.60 PcsComp Mainboard Configuration Tool?

@00:d8:61:84:32:79 192.168.1.99 Microstar International (MSI) Mainboard ...

The only valid CIP traffic seen in the log is between the "Configuration Tool /

Rockwell PLC Software" at 192.168.1.60 and the Rockwell PLC at 192.168.1.10.

Also a lot of TCP Connection open requests (SYN packets) to the well known CIP 

port 44818 (0xaf12) can be seen originating from the PLC (192.168.1.10) to the 

MSI Board (192.168.1.99). See packet pairs at packet number 1181/1182, 1221/1222,

1272/1273 and so on.

I guess your OpENer programm is running on the MSI board at 192.168.1.99 under

Windows. The TCP open requests are immediately denied with a RST packet. It

looks like the Windows firewall interferes with the operation of OpENer.

As a quick test you should disable the Windows firewall completely to see if

you get any communication running.

If the firewall is the culprit I have two ideas for a long term solution:

a) If you have a dedicated interface only for the EtherNet/IP traffic you could

  disable the firewall selectively only on that interface.

b) You could install OpENer always at the same location and configure an exception

  rule in the firewall for the OpENer program only.

Best regards,

    Stefan

[Sakontanut]

Hi, 

I have tried to disable Windows firewall in MSI board(192.168.1.99) and also the VM VirtualBox(192.168.1.60), but the same error still occurred. Is there any other reason? Thank you in advance.

Best regards,

Sakontanut

[stm-at-esd]

Hi,

you did not confirm that the OpENer is running on the MSI board(192.168.1.99). I can only give general hints how to get the communication work.

a) At best you should use a dedicated network for the EtherNet/IP devices that is not connected to your office network. This will make everything easier.

b) Start OpENer on the machine that is intended to act as EtherNet/IP device.

c) Check (under Windows) that the OpENer listens to the right IP address / interface of your machine (the one that is intended to be the EtherNet/IP network

  and not your office network interface). There should be a listen socket for TCP and also two listen sockets for UDP on port 0xAF12 (44818).

d) Check that the firewall of the machine OpENer runs on is disabled at least for the EtherNet/IP interface.

e) Try to solicit a response from the OpENer machine by sending a broadcast ListIdentity request on the EtherNet/IP network from another machine. You may

   use the Molex EIPTool (downloadable from Molex after registration at https://www.molex.com/molex/common/staticLoader.jsp?fileName=/mx_upload/superfamily/iccc/EtherNet_IPTool.html) or the EtherNet/IP Explorer (https://sourceforge.net/projects/enipexplorer/).

f) If step e) works successfully and you have played around a little bit with the mentioned tools you may try to plug your Rockwell PLC to the EtherNet/IP

  network trunk and see if you can get an EtherNet/IP connection up and running.

I hope that helps.

Best regards,

    Stefan