Hello.

I was going through your responses from yesterday, and I noticed one thing: When I asked you to used the loopback adapter, you have switched both the publisher and the subscriber to it.

I no longer have access to the computer that had the similar problem, and the instructions we wrote in the Knowledge base are unfortunately not clear in this respect. But I think the resolution was different: Keep publishing to the original interface ("Ethernet 3" in your case, I believe). And only reconfigure the subscriber to use the loopback adapter. Can you try that too? Please use OpcCmd as the subscriber, because with it I can control easily what is happening. If we make OpcCmd work we can then proceed to other tools.

Best regards

Thank you for the PCAP file. There is no problem in principle in seeing the messages from your publisher - see the picture below.



I can see there are actually two publishers (1 and 2), etc.

You can do that too, I can tell you how, if you like, but that's not the point. We now know that the problem is really at the physical level. It is possible to interpret the messages - if they come from the PCAP file. But not from the network card.

I will reply later (tomorrow I think) if/when I get some idea where to look next.

Best regards

If OpcCmd does not show anything, Connectivity Explorer won't work either. But I want to note, just to be sure, that you know that if you change anything in the point settings (Inspect tab), you actually need to "Add Live Data Row" with the modified data (create a NEW row) - the changes don't affect the existing rows.

Hello,
and thanks again.

I do not see anything wrong with the way you are doing it.

Can you make a Wireshark capture (save in the PCAP format please) with at least one PubSub message, and post it here? (I tend to think the problem is that no messages are received at all, at the transport level, but by doing this, I want to inspect the message to see whether it can be processed by us - in case it *is* received).

Thank you

Hello,
thank you for your answers.

I think there might be actually multiple problems at hand. The QuickOPC version/build is correct (it is the latest one).

For the first one:

Can you please visit kb.opclabs.com/OPC_UA_PubSub_Common_Traps_And_Pitfalls and try the suggestion under "Subscriber does not receive anything, when on the same host as the publisher." (i.e. add a dedicated loopback adapter?) . Alternatively, run the publisher on a computer different from the subscriber.

Then, repeat the test with OpcCmd, specifying the new interface name instead of "Ethernet 3".

Only after we can make the test with OpcCmd work, we can proceed to other tests and possible fixes (for record - and before I forget: In the Connectivity Explorer, it might be necessary to explicitly specify the interface name; in the PubSub demo app test, the 'writer' filter should be cleared).

Also note that even after we make the data go through, the variable shown on the Connectivity Explorer does not use a simple OPC UA data type, but rather a custom structure. We have support for that too, but I would not be surprised if it takes further work.

Best regards