Hello,
I have a system connected via an ethernet hub. It contains an OPTO22 SNAP-UP1-ADS Ultimate I/O controller and 2 OPTO22 SNAP-E3000-ENET Ethernet I/O brains. The controller can communicate with the brain, and I can see the inputs and outputs functioning properly.
However, when I try to access the PAC Terminal or PAC Manager, I get a communication error, and it gives me the code -10057, which means the Ethernet Socket is not connected. I can see that the devices are connected to the network because when I ping them in my command console, they successfully send messages back.
Interestingly, I was able to view them in the Manager 2 days ago, which was when I was able to copy the I/O configuration from one brain to the other (there was an issue with one of the outputs). That has fixed my system and is working as intended but I would like to go into the controller and download the contents for a backup.
I have completely disabled all firewalls and also tried accessing them when enabled with rules and expectations. I would like to access the devices again which is frustrating because I was able to for some unknown reason.
Any troubleshooting tips would be greatly appreciated—much thanks in advance.
Sounds like the UP1 is out of TCP communication handle sockets.
Do you have any polling software or TCP devices besides the B3000s on the network?
The reason you could access it the other day, but not now is that you had just a few remaining sockets free for the incoming connection from your PC.
Normally they free up over time, but if you have an aggressive I/O handler or some other traffic on the network that is keeping connections alive, then you do run out of free connections on the TCP/IP stack.
Depending on your process and if it can handle any down time, you only have two options.
You can try unplugging the Ethernet from the UP1, count to about 20 or 30 and plug it back in. Sometimes that will free up some connections and let you back in.
Reboot. That’s the sure way to flush the stack and start over, but it depends on your process and your strategy handing such an event.
Unfortunately, I don’t think it is a socket issue. I have tried the steps listed above and even reset the stack in the command consol but no luck. I only have the three devices, and this computer connected to the HUB. I also ran NMAP to check the ports available for each device and 2001 and 22001 are open on the corresponding device. Are there any other things I can try?
This is what I found on the internet. I’m not sure if it would even work for my local network but I thought it was worth a try.
I am still not able to access the devices which is quite annoying because I’ve seen that it is possible the other day.
I was trying to trouble shoot initially with 2 of the devices because one of the brains is just a redundant system. However, I then requested the other side so I could have the whole system and once I hooked it all up, it still didn’t work right away but after testing, I found the brain that was not working problem had a problem with the program and it wasn’t a hardware issue. I then went into the manager. I was able add the third device and it just started to work. I came back the next day and I’ve ran into the same issue of not being able to access any of them.
Ah, Ok, I see the command.
That wont reset the stack on the SNAP-UP1.
Did you unplug the Ethernet from the SNAP-UP1 on the top of the controller?
That’s only a suggestion if you cant reboot (power cycle) the SNAP-UP1 itself which is the sure fire way to flush the TCP/IP stack in the controller.
Yes, I have. I have power cycled it because the system is not yet installed, and we are trouble shooting it right now. One thing I noticed is that I had an operational message for the controller, but the brains had a message that said something about could not send power to the device. However, I was still able to access them in the manager.
I recommend that you contact our support group.
They can help guide you through it, I don’t have a SNAP-UP1 on hand even, they are getting along in age.
