Not reading from CJ2M CPU

[Archie]

My mistake... I see what happened. You will need to do this fix.

- Open AdvancedHMIDriver\Omron\FINS\FINSBaseCom.vb
- Go to line 603
- Modify the code to this:

            Dim FINSPacket As MfgControl.AdvancedHMI.Drivers.Omron.FINSFrame
            '* MR=1, SR=1
            '* 11-JUN-15 A 0xff was going in the bit position if no bit specified
            Dim BitNumberByte As Integer = SavedRequests(CurrentTNS).BitNumber
            If SavedRequests(CurrentTNS).BitNumber < 0 Or SavedRequests(CurrentTNS).BitNumber > 64 Then
                BitNumberByte = 0
            End If
            Dim data() As Byte = {SavedRequests(CurrentTNS).MemoryAreaCode, CByte((SavedRequests(CurrentTNS).ElementNumber >> 8 ) And 255), CByte(SavedRequests(CurrentTNS).ElementNumber And 255), _
                                  CByte(BitNumberByte), CByte((SavedRequests(CurrentTNS).NumberOfElements >> 8 ) And 255), CByte(SavedRequests(CurrentTNS).NumberOfElements And 255)}
            FINSPacket = New MfgControl.AdvancedHMI.Drivers.Omron.FINSFrame(Header, 1, 1, data)

[fbowman3]

The Bit is now showing 0, but i'm still not reading any data.

[Archie]

So here is a side by side of the KEPware versus AHMI with the differences flagged:

80   80
00   00
02   02
00   00
0b   00     Destination Node number (Set in the driver by TargetNodeAddress property)
00   00
00   00
37   fb      Source Node Number (should not matter)
00   00
03   71     Service ID (always changes based on packet)
01   01
01   01
82   82
00   00
00   00
00   00
00   00
01   01

This leaves the only difference is the node number. KEPWare uses 0x0b (11), which matches the last byte of the IP address.  By setting TargetNodeAddress in the OmronEthernetFINSCom driver to 11, should make these bytes match up.

[fbowman3]

I've used TargetNodeAddress 11 to match the plc and the bits all match up but it still does not get any read results. I may just have to try using the peripheral port on the PLC instead of etherent.

[fbowman3]

Here is my last wireshark capture with the node address set to 11

[Archie]

I think I see the problem. I noticed that every time a packet is sent, the PLC responds with a broadcast looking for 192.168.250.251.... The packet sent just happens to use a source node as 0xfb which is 251. I originally didn't think that mattered, but it apparently does.

One last thing to try...

- Edit AdvancedHMIDrivers\Omron\FINS\OmronEthernetFINSCom.vb
- Go to line 50
- Change the &HFB to &H37

            '* default port 1 (&HFC)
            SourceAddress = New MfgControl.AdvancedHMI.Drivers.Omron.DeviceAddress(0, &H37, 0)

[fbowman3]

Still no luck after that change. Definitely getting some different data on the wireshark capture though. Thank you for your support on this, It is greatly appreciated.

[Archie]

We definitely got a response now. Packet 3 is the request and Packet 4 is the Memory Area Read response. The value returned is a 1

If you now put a BasicLabel on the form and set PLCAddressValue to D0, what will the BasicLabel show?

[fbowman3]

unfortunately i still see no response on AHMI. Label still reads "BasicLabel". Value and Click are set to D0. I can change the value by the keypad but not see it.

[Archie]

Now that we know the PLC is responding with data we have to figure out why it doesn't get back to the BasicLabel. In FINSBaseCom.vb at line 931 (or close to) is the sub where the data should come back to:

        Protected Sub DataLinkLayerDataReceived(ByVal sender As Object, ByVal e As MfgControl.AdvancedHMI.Drivers.Common.PlcComEventArgs)


Put a breakpoint in the first line of code of that sub by clicking in the left margin.

            If e.RawData Is Nothing OrElse e.RawData.Length < 12 Then

Run the app and when it stops at that breakpoint, click F10 to begin stepping through the code.

The area of interest is line 965:

            If Fins.EndCode = 0 Then

We need to see if the error is 0 and it steps to the next line. Ultimately we need to see if it gets to line 979 which is where the value is sent back to the BasicLabel:

                            SendToSubscriptions(e)

[fbowman3]

I'ts not breaking at that point. Not sure if i'm doing something wrong or not. It doesn't look like that sub is getting triggered?

[Archie]

Looking back at the last packet capture, I see the request is over TCP, but the response is UDP. Try changing the UDP port number again and do another capture. It's almost like the PLC sees the request come on port 9600 and only replies in UDP even though the request came in on TCP.

We're making progress and getting close, but there must still be something minor.

[Archie]

I have seen this mentioned on a couple other forums where the UDP and TCP have to be on different ports:

http://forums.mrplc.com/index.php?showtopic=24303

http://www.plctalk.net/qanda/showthread.php?t=79504

[fbowman3]

UDP port setting was changed to 9650. Updated Wireshark Capture attached.
The breaking point at If e.RawData Is Nothing OrElse e.RawData.Length < 12 Then is not getting triggered.

[Archie]

I'm just not sure if this processor supports FINS/TCP. That last Wireshark shows a request on TCP port 9600, but the response comes back on UDP port 9650.

I'm going to see if I can add a UDP option to the driver.