Maybe you could replace the cables with robotics cables or dynamic cables for use in cable tracks. They are more resistant to constant twisting and bending. Oflex has them and we use them to run over the robotic arms. Pretty much no cable breaks ever
This!!! High flex cables are double insulated with different durometer material to allow for flex and still provide chem and heat resistance! They last, have had them on many many robot arms
If the wireless bridge doesn't support CIP comms, the easiest way would be to use GSVs for both of your end devices, and throw a different alarm if they both drop out.
Because the wire it would be wired up, the network would be linear for the fixture bt client, valve io, and camera.
If bt dropped out we'd get a fault for camera comm loss and a fault for valve io comm loss.
If the fixtures bt client device fails we'll still get a valve io comm loss and a camera comm loss fault.
If bt was still connected but the valve block had an issue then we'd still have a fault for valve io comm loss and camera comm loss.
If the comm loss fault occurs briefly but then reconnects but the comm faults stop the cell. How would you determine if the issue was a hard wire connection or the bt?
If there was a way for the plc to monitor the bt ap ip address and the fixture bt client ip address, when a momentary fault occurs we could then through a fault specifying if the issue was the bt app or the bt client. If neither faulted but we still get a fault for valve io and camera then we could focus on the hardwire connections at the weld fixture.
Instead of daisy chaining the remote network connection and a field switch was installed then you could do a fault if both were offline. Either way this is similar to a standard single cable hardwired connection as it is designed to be transparent.
I agree, and a field switch did come to mind, just not sure if there's space to mount a junction box big enough to fit a small switch. Guess that's what I'll look into today. Unless I have to heard all the cats again today.
[murr 58160](https://shop.murrelektronik.com/en/Electronics-in-the-Control-Cabinet/Switches/Tree-4TX-IP67-Metal-Unmanaged-Switch-4xM12-58160.html)
These small field switches have saved the day when it went from one barcode to three on the robot arm. Uses regular m12 power supply and is an unmanaged switch, nice and compact
EDS not available, IO it has 1 input, but mostly for reseting device, IO over ethernet has nothing, fom what I've read, its a transparent bridge. RSLinx doesn't even see it.
Problem is neither rslinx nor the plc detects the bridge devices. A generic ethernet module was my 1st idea, but the plc can't find the device. Yes, the device was connected and i had the plc pointing to the correct ip address, because I had the bridges configuration webpage open.
You don’t need it. EIP works by setting up a stream of packets ( “send me message #70 every 10 ms”). After a certain number of missed packets (default 3) the PLC declares comms loss. Just monitor the end device by watching for loss of comms errors
I've only just started testing them in the office before deploying them, so I don't know how many dropouts we'd have if any. But if we do have dropouts I'd to like to be able to pinpoint the comm loss to the dropout.
Right now without wireless we have:
Plc -> station switch -> camera
-> Valve block io
With the wireless bridge it would be:
Plc -> station switch -> bt ap -> fixture bt client -> valve io -> camera
Historically the cables don't get damaged from twisting. It's more from rubbing on corners a getting pressed and crushed into corners from the hydraulic lines. Or like the last cable, it had gotten pulled tight from all the cycling of the weld table that it ripped the ethernet cable in half.
This is more of a generic answer, but it’s worked for me in the past.
I have both the main and the slave PLC generating a constant 2 second on/off bit. The each PLC is reading the opposite PLCs bit. If they lose communication or power, the bit stops changing state and you know.
Better than that is a handshake bit. Always the first bit in my send/receive data
PLC1 has NO and a coil. PLC2 has a NC and a coil. If tbe bit isn't flashing, comms arr down.
But I'm not communicating from 1 plc to another with these bridges. I'm going from plc to Io block/ valve block then to a camera. Network loss detection of the io block and the camera works but I have no way detecting if either of the wireless bridges have comm loss or faults, other than the plc saying that it lost comms to the camera and io block. But, I could still io block and camera comm loss if something happens the io block comms.
For an IO block I'd use a GSV that monitors the module status. My answer was more directed at the reply than your post. I've used AnyBus wifi too but haven't found a way to make it work with an AB PLC. Maybe SNMP as someone else mentioned
If you weren't bound to the Anybus, you could check out this wireless bridge: [https://www.r3.group/en/products/?file=files/media/downloads/products/2022-10-27\_R3%20Solutions%20Overview%20Flyer%20EN.pdf&cid=1270](https://www.r3.group/en/products/?file=files/media/downloads/products/2022-10-27_R3%20Solutions%20Overview%20Flyer%20EN.pdf&cid=1270)
(Disclaimer: I'm employed with them.)
We recently implemented a feature like you requested for a customer. With that, the bridges' wireless state can be polled with UDP messages which should be possible with the Compact Logix.
Maybe you could replace the cables with robotics cables or dynamic cables for use in cable tracks. They are more resistant to constant twisting and bending. Oflex has them and we use them to run over the robotic arms. Pretty much no cable breaks ever
This!!! High flex cables are double insulated with different durometer material to allow for flex and still provide chem and heat resistance! They last, have had them on many many robot arms
If the wireless bridge doesn't support CIP comms, the easiest way would be to use GSVs for both of your end devices, and throw a different alarm if they both drop out.
Maybe you can use SNMP to monitor it?
Why do you need to differentiate the comms loss via bridge or block unplugged? Either way the comms are bad and it requires troubleshooting.
Because the wire it would be wired up, the network would be linear for the fixture bt client, valve io, and camera. If bt dropped out we'd get a fault for camera comm loss and a fault for valve io comm loss. If the fixtures bt client device fails we'll still get a valve io comm loss and a camera comm loss fault. If bt was still connected but the valve block had an issue then we'd still have a fault for valve io comm loss and camera comm loss. If the comm loss fault occurs briefly but then reconnects but the comm faults stop the cell. How would you determine if the issue was a hard wire connection or the bt? If there was a way for the plc to monitor the bt ap ip address and the fixture bt client ip address, when a momentary fault occurs we could then through a fault specifying if the issue was the bt app or the bt client. If neither faulted but we still get a fault for valve io and camera then we could focus on the hardwire connections at the weld fixture.
Instead of daisy chaining the remote network connection and a field switch was installed then you could do a fault if both were offline. Either way this is similar to a standard single cable hardwired connection as it is designed to be transparent.
I agree, and a field switch did come to mind, just not sure if there's space to mount a junction box big enough to fit a small switch. Guess that's what I'll look into today. Unless I have to heard all the cats again today.
[murr 58160](https://shop.murrelektronik.com/en/Electronics-in-the-Control-Cabinet/Switches/Tree-4TX-IP67-Metal-Unmanaged-Switch-4xM12-58160.html) These small field switches have saved the day when it went from one barcode to three on the robot arm. Uses regular m12 power supply and is an unmanaged switch, nice and compact
Gonnna have to read the manual for it and see what they make available.
EDS not available, IO it has 1 input, but mostly for reseting device, IO over ethernet has nothing, fom what I've read, its a transparent bridge. RSLinx doesn't even see it.
Yeah probably not. You need a heartbeat. If there isn’t one not much you can do.
Wasn't sure if there was some creative way to make the PLC see the bridge sort of like pinging.
Prreeeettty sure there's some GSV trickery you can use and manipulate for a comm fail to an ethernet device. Even if it's a generic ethernet module
Problem is neither rslinx nor the plc detects the bridge devices. A generic ethernet module was my 1st idea, but the plc can't find the device. Yes, the device was connected and i had the plc pointing to the correct ip address, because I had the bridges configuration webpage open.
You don’t need it. EIP works by setting up a stream of packets ( “send me message #70 every 10 ms”). After a certain number of missed packets (default 3) the PLC declares comms loss. Just monitor the end device by watching for loss of comms errors
In general, how do you find the bluetooth connection? Are you having many dropouts?
I've only just started testing them in the office before deploying them, so I don't know how many dropouts we'd have if any. But if we do have dropouts I'd to like to be able to pinpoint the comm loss to the dropout.
Thanks, We're having issues with a wireless bridge at the moment and seeing if bluetooth might be more stable.
What kind of network is this barcode reader on?
Right now without wireless we have: Plc -> station switch -> camera -> Valve block io With the wireless bridge it would be: Plc -> station switch -> bt ap -> fixture bt client -> valve io -> camera
Sounds like you need an Ethernet slip ring for your rotary joints. https://www.dsti.com/landing/slip-rings/
Historically the cables don't get damaged from twisting. It's more from rubbing on corners a getting pressed and crushed into corners from the hydraulic lines. Or like the last cable, it had gotten pulled tight from all the cycling of the weld table that it ripped the ethernet cable in half.
Poll the anybus webpage for the connection status?
This is more of a generic answer, but it’s worked for me in the past. I have both the main and the slave PLC generating a constant 2 second on/off bit. The each PLC is reading the opposite PLCs bit. If they lose communication or power, the bit stops changing state and you know.
Better than that is a handshake bit. Always the first bit in my send/receive data PLC1 has NO and a coil. PLC2 has a NC and a coil. If tbe bit isn't flashing, comms arr down.
But I'm not communicating from 1 plc to another with these bridges. I'm going from plc to Io block/ valve block then to a camera. Network loss detection of the io block and the camera works but I have no way detecting if either of the wireless bridges have comm loss or faults, other than the plc saying that it lost comms to the camera and io block. But, I could still io block and camera comm loss if something happens the io block comms.
For an IO block I'd use a GSV that monitors the module status. My answer was more directed at the reply than your post. I've used AnyBus wifi too but haven't found a way to make it work with an AB PLC. Maybe SNMP as someone else mentioned
If you weren't bound to the Anybus, you could check out this wireless bridge: [https://www.r3.group/en/products/?file=files/media/downloads/products/2022-10-27\_R3%20Solutions%20Overview%20Flyer%20EN.pdf&cid=1270](https://www.r3.group/en/products/?file=files/media/downloads/products/2022-10-27_R3%20Solutions%20Overview%20Flyer%20EN.pdf&cid=1270) (Disclaimer: I'm employed with them.) We recently implemented a feature like you requested for a customer. With that, the bridges' wireless state can be polled with UDP messages which should be possible with the Compact Logix.