Doesn't excuse using LL addresses. One day it might wake up with a different address.
Troubleshooting this should have started with some logs anyway.
Set all the loggers you find searching drivers.LogixDriver to DEBUG (see Diagnostics - Logs - Ignition User Manual 8.1 - Ignition Documentation)
Once the level is changed, go edit and save the device configuration in the Gateway.
After ~15 seconds get the logs and upload them.
3 Likes
I did some research into the tshark issue and it seems that even when you run it as root, it actually drops privileges before it gets to the file writing. Fun with bug patches being submitted and rejected, all that.
850768 – tshark with -w option fails if file does not exist
One workaround I found was to make the file first, change the permissions so that tshark could access it, and then write to it:
YMMV
2 Likes
If you're having issues with tshark, give tcpdump a try with something like this:
tcpdump -i any -nn -w capture.pcap host 169.254.128.178
Then use Ctrl+C to break after you're done capturing some packets (they hopefully scroll by on your screen as well).
But as @pturmel pointed out, you really shouldn't be using that IP in the first place. Pick, a couple static IPs in the 192.168.x.x range or 10.x.x.x for the PC and PLC. Also, avoid using 192.168.x.1 or 10.x.x.1 as if this ever needs to be connected to a larger network, those are the most common IPs for routers/firewalls and it just creates a headache later on.
4 Likes
From your logs:
invalid connection path: 169.254.128.150:44818
java.lang.IllegalArgumentException: missing path component, count=1
at com.inductiveautomation.xopc.drivers.logix.util.ConnectionPathParser.parseUnsafe(ConnectionPathParser.java:39)
at com.inductiveautomation.xopc.drivers.logix.LogixDriver.getConnectionPath(LogixDriver.java:364)
at com.inductiveautomation.xopc.drivers.logix.LogixDriver.<init>(LogixDriver.java:191)
at com.inductiveautomation.xopc.drivers.logix.LogixDriverType.createDriver(LogixDriverType.java:26)
Looks like you stuck an IP address and port into the Connection Path property for some reason.
1 Like
Figured out the issue, the PLC had faulted to due to two devices having the same IP and it was not clearing, still do not know why my test Micro Logix PLC wouldn't work, but I do not care right now. Cleared the fault code and all is good.
1 Like
That was suggested on post 6. It can happen to the best of us.
2 Likes
Actually, after having to do this to a second deployment today, I have realized that for some reason the PLC will not talk to the linux machine unless I ping it from my laptop that's running windows. After that it is fine, I have no idea why.
Did you ever switch to using good static IPs or are you still using the link-local IPs starting with 169.254.x.x? If you haven't switched to static IPs, I highly suggest doing so as this may be part of your issue.
3 Likes
No, Senior Engineer wants it like that and again these PLCs will never see any other network once they ship.
Your Sr Engineer should really rethink this. There's been multiple times I've heard that same argument that "this will always be an isolated network" and then later on comes back to haunt them. It's an easy fix if you do it up front, but once in the field and operational can be a headache to fix.If it's "never" going to be connected to another network, then I don't know why they'd have an issue swapping to a different IP subnet now. Also, you mentioned that it wouldn't talk to the PLC until you pinged it with a Windows PC. If this was never resolved (have you done a full power cycle of all equipment (PC, PLC, switch, etc) to make sure it comes up without this same issue? If it always needs pinged by a Windows PC before it will work, that's a show stopper.
1 Like
I agree. 169.254.x.x is a public IP address. You should be using private addresses internally.
When I was much less knowledgable I added multi-NAT routers to a series of identical machines that had been shipped to us with 200.200.200.0 LANs. After I configured the gateway settings on the PLC, HMI and safety relay the PLC couldn't see the safety relay anymore. I explained my problem on the appropriate router forum and someone pointed out to me that the PLC's request to the safety PLC, 200.200.200.4 (or similar), was being routed to a telco in Brazil (and I'm in Ireland). Switching to private IPs solved the problem. It was a lesson that took me two days to learn.
Worth a read ...
The windows ping was only required the first time, no idea why. Also, this PLC will never be allowed to connect to anything else. I wish I could describe my project farther, but believe me when I say the IP address really doesn't matter on this one. This isn't control any industrial equipment or anything like that.