AdvancedHMI Software
General Category => Support Questions => Topic started by: fbowman3 on June 08, 2015, 02:13:54 PM
-
I've used AHMI with a Click PLC across modbus/tcp with no problems. I have been trying to read/write to an OMRON CJ2M with OmronEthernetFINSCom with no luck. I have the IP set at 192.168.250.11 and the network & node at 0. I'm trying to read D0 & W1.02 but not having any response. There are not errors either. I can create a basicbutton and turn on bit w1.02. I'm using Visual Studio 2013. Does my PLCAddressValue have to be set to something other than D0 or W1.02?
-
I don't have a CJ2M to test with, but I did a quick test with a CP1H and everything worked as expected. This is the test I did:
- Add an OmronEthernetFINSCom to the MainForm
- Set the IP Address to the address of my controller which is 192.168.0.1
- Set my laptop IP Address to 192.168.0.99
- Added a BasicLabel to the form
- Set PLCAddressValue and PLCAddressKeypad both to D0
- Ran the application
- Clicked on the BasicLabel and entered a new value
- The BasicLabel then showed the new value from the PLC
My program in the PLC decreases the value of D0 until it reaches 0 just so I can see the value is being continuously updated from the PLC.
The best way for me to see exactly what is happening is for you to run a WireShark capture while reading/writing data, then post the capture. I will be able to see the data going to the PLC and whether it is responding.
-
Here is my Wireshark capture.
I started a new HMI file with only an OmronEthernetFinsCom set to 192.168.250.11 and a BasicLabel to Read/Write D0.
My Computer IP is set to 192.168.250.55
-
I would need the actual saved file from WireShark
-
My apologies...
-
This is what I am seeing. Packet 5 is the request for D0. The PLC acknowledges that is received it in Packet 7. However it never responds with any data.
Searching around the internet I see some mentions of the CJ2 supporting UDP. One person even mentioned something about changing the port or disabling UDP. Do you see any kind of settings for both UDP and TCP? The AdvancedHMI driver only uses TCP.
-
I tried changing the Fins/UDP port with no luck.
These are some settings that can be changed on the PLC
-
If you changed the UDP port to User Defined and something other than 9600 and it made no difference, then maybe there is a node problem.
There are addresses sent in the packet.
DNA - Destination Network Address
DA1 - Destination Node Address
DA2 - Destination Unit Address
In the Wireshark capture, all of these are showing 0. Are there any other settings in the PLC that may have changed these from 0s?
-
I don't believe they were changed anywhere else in the program/settings. I found a CJ1M-CPU11 and connected that up (no ethernet/ip option on it). Same problem. I can write to bits & words but i cannot read any data.
-
I am running out of ideas on this. The Wireshark captures are showing the correct FINS request going to the controller and the controller even acknowledges that it received it, but never responds with data. The only controller I have that supports FINS/TCP is the CP1H, so I am unable to test with the same hardware.
Do you have any other software such as an OPC server that you can use to read D0 and do a WireShark capture? From that I can see how the packets compare. I was looking at the Kepware OPC server, but it shows that it only support UDP and not TCP.
One more things to try. In the OmronEthernetFINSCom1 driver properties, set the TargetNoteAddress to 11, which is the last byte of the PLCs IP Address. I remember having to do something like that on a CS1 controller.
-
I've changed the TargetNodeAddress and TargetNetworkaddress with the same results or no communication at all. I just installed and ran Kepware on my computer and was able to read data from the PLC. However, it is only communicating UDP. Here is a wireshark capture of the Kepware session.
-
I do see one significant difference from the KEPWare packet. Attached is patch that will change the 1 byte to the same as what is used on the KEPWare driver.
- Download and extract the attached file
- Replace the file found in AdvancedHMIDrivers\Support with the attached file
- Open solution in Visual Studio and do a Rebuild Solution
If it doesn't work, post another WireShark and I will compare further.
-
Still getting the same behavior. I did a wireshark capture with the UDP port set to 9600 and one with the UDP port changed to 9650.
-
It doesn't look like the patch applied. I'm still seeing the 0xff in the capture where it should be 0x00
Check in your AdvancedHMI\bin\Debug directory to see what the date is on the file MfgControl.AdvancedHMI.Drivers.dll
It should be today's date at 8:07AM
-
I verified the patch update. Copied & replaced the driver.dll file and rebuilt the solution. still getting the 00xff.
-
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)
-
The Bit is now showing 0, but i'm still not reading any data.
-
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.
-
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.
-
Here is my last wireshark capture with the node address set to 11
-
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)
-
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.
-
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?
-
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.
-
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)
-
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?
-
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.
-
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
-
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.
-
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.
-
A new version of 3.98p is now available. This new version has an additional property of ProtocolType. Try setting this to UDP.
One thing I did notice is that UDP takes about 5 seconds to start up. I did not get to investigate to see why because I wanted to get this out quickly for testing that is works at all.
-
It Works! It does takes a good 45 sec. for it to start reading/writing data on my end.
-
That's good news. Thanks for all the patience and feedback. This week I'll see if I can figure out why it takes so long to start up.
-
Version 3.98s fixes the slow connection time. On my PC it connects within a second now.