Wireless Bolt needs power-up reset

Anybus Support Anybus Wireless
#1

I recently installed Wireless Bolts on 2 overhead industrial cranes, with a centrally located Cisco Aironet 3700 series access point.
One of the cranes has worked fine since day one using firmware ver 1.1.6, but the other needs to constantly be power reset to re-establish communications.
I upgraded the firmware to 1.3.9, relocated the Bolt for better line of site with the AP and set the Cisco AP to a fixed channel of 1, but still no good.
The uptime can vary from minutes to hours, but when the link is lost with the AP, I need to power reset the Bolt to re-establish comms.
I suspected the Bolt was faulty, so I installed our spare Bolt, but this did not solve the problem.
The Bolt is setup as follows:
Static IP, Bluetooth disabled, Layer 3 IP Forward, 2.4GHz Client, DHCP Server disabled.
The Cisco AP radio channel was originally set to “Least Congested Frequency”, but is now fixed on channel 1 after testing 1, 6 and 11 with no improvements.

Can you please explain why the Bolt needs to be power reset and is there a way I can set the Bolt to auto reset comms?

#2

Hello,

I need to look into this further and get back to you. Thanks!

Nick

#3

Hello,

Sorry for the delay, but this is a known bug, and we are actively working on fixing it. I will let you know as soon as we have a firmware to fix this.

Best regards,
Nick

#4

Thanks for the reply.
Is this only an issue with the latest firmware 1.3.9 and not 1.1.6?
I have a Bolt with 1.1.6 and it has been working fine.
Can I downgrade the firmware and try it?

#5

Hi Chris,

We will need to verify exactly what firmware this issues seems to be tied to. You also can not downgrade down to the 1.1.6 FW from the internal webpage. You can go to FW1.2.3 which is the SP2 download from our site.

Deryck

#6

Hi Chris,

Funny, I have been dealing with this same issue since we purchased 10 of these Bolts back in December.
At first, the maintenance team was blaming my wireless network, but we have 4 eWON Flexy with wireless on the same AP without any issues. I also thought it was the cheap micro820 PLC, but we see this happening on Bolts with CompactLogix PLC too.

I know HMS is working to fix this in a firmware update. I wonder if its possible to keep these Bolts connected to our AP’s if we send a constant ping to the PLC or pull a simple tag like the date/time to keep the connection alive?

Wireless Bolt does not reconnect to WiFi after data inactivity loss
#7

Hello,

It is really difficult to say if this would make a difference, we are not sure of any work way to work around at this point. We have not recreated this issue in our local lab, so we are unable to test at this moment.

Thanks!

Nick

#8

Hello!

Cannot say I’m glad, but it is good to see someone else with the same problem. I have been troubleshooting our Cisco network believing that the problem was located there… we are using bolts to connect ABB profinet IOs. It behaves the same. It is up and running, could be anything between hours to days when it suddenly stops and needs to be rebooted.
Hope to get a solution to this fast, as we like the design of the product but need to get them working, or we don’t have any other choice but to look for another product.
Is it possible to downgrade the firmware anyhow? We tried replacing a bolt running an earlier firmware (not sure which) with one running latest 1.3.9. Need to check what firmware they where delivered with.

#9

Hello @Dahlberg,

The developers are working on this issue and we expect to see a fix soon. I will see if I can get a more accurate time frame.

You can downgrade the firmware using the devices firmware page. if you are on 1.3.9 you should be able to go all they way back to FW 1.2.3 .

Deryck

#10

Hi Deryck,

Do you have any updates yet from your developers, for an estimated timeframe on a fix for this issue?

#11

No update at this time. I will update this thread as soon as we have more info.

#12

I downgraded one of our Bolts from version 1.2.3 to 1.1.6 yesterday, using the Firmware Manager 2 application.
I hope it is going to be installed today and hopefully it will be running OK.
Our Bolts are configured with default IP, Layer2 cloned-mac, 2,4GHz Client.

#13

The 1.1.6 Bolt was installed and running at 16:00 yesterday and has been online since!

#14

Hello Dahlberg,

Good to hear you have gotten the connection to be stable. Were you having the same issue on 1.2.3 FW?

Deryck

#15

I downgraded from V1.3.9 to V1.2.3 and couldn’t get it online again, V1.3.9 at least worked, it just wouldn’t re-establish comms if the link was lost and needed a power-down reset.
I was told I couldn’t downgrade to V1.1.6, but Dahlberg was successful and now appears to be working.
Where can I download the “Firmware Manager 2” application, as per Dahlberg reply?

#16

I will need to test it myself but with firmware Manager II you should be able to revert back down to (1.1.6) Service pack 1.

Deryck

#17

I was able to downgrade to V1.1.6 SP1 and the Bolt has now been running successfully for the last 2 days!
If the WiFi connection is lost due to range (mobile overhead crane application), the Bolt is now capable of re-establish the link with the AP when back in WiFi range.

#18

Is this lockup issue a known issue with the AWB II as well?

I recently installed a pair of bridges in a new overhead gantry crane system. The client bridge unit is on the crane, connected to an unmanaged switch with multiple devices connected to it (AB CompactLogix, two Ethernet/IP devices, an AB Ethernet/IP VFD). The CompactLogix also has an Ethernet/IP connection to an IO device on the land-based side, and there is a AB Panelview and another PLC communicating with it across the wireless link as well.

Both the land-based AP and the remote Client bridges are running F/W 1.2.3 (installed out of the box). The client bridge mode setting is configured for “Layer 3 IP forward”.

Normally this setup works fantastic. I can also connect to the CompactLogix controller over the wireless link with no disruption whatsoever. The throughput seems very good.

But on three occasions now the wireless link has locked up. In this situation all communication is lost across the wireless bridge. The System Overview page on the AP bridge doesn’t indicate anything out of the ordinary, and still shows the MAC of the client unit as connected. But the client IP address does not ping.

During one instance, the WLAN LED on the client appeared to be blinking purple, as if it was scanning for an AP, and the WAN and LAN LED’s were off on the AP bridge. Also the link quality LED’s were off on the client bridge. In the most recent incident though, the LED’s on both units indicated normal operation.

In all cases cycling power on the client bridge fixes the communication and everything begins working normally again.

Is a downgrade to a previous F/W rev the suggested workaround at this time?

Thanks

#19

Hello,

This does for sure seems to be the same issue, however with the AWB II I do not think there is an option to move down another firmware revision. I will need to check on this.

Best regards,
Nick

#20

Hello @kbrewster,

You would be able to downgrade to 1.1.6 to fix the issue the is requiring a reboot. This does reintroduce other bugs but if you are using two devices in bridge mode you should not see much change. The firmware was also never officially released for AWBII so there could be unexpected issues.

To downgrade will need to use Firmware Manager II available here > https://www.anybus.com/support/file-doc-downloads/anybus-support-tools?orderCode=tools

Deryck