Allen Bradley Flex I/O Help

woogie362

Member
Join Date
Apr 2008
Location
wisconsin
Posts
5
We are trying to set up a 1794-ADN flex I/O module to a robot controller. Our mod/net Status is blicking red, so I went to ab.com to find the error message, and all that it says about it is that it is a recoverable fault. Any ideas as to what needs to change? How I can fix it? Is this a problem with the robot controller, or with the flex I/O?
 
Does your robot controller have any diagnostics for the status of it's I/O connections ? If this is an identity or I/O connection size problem the master is going to know.

What's the I/O LED on the 1794-ADN doing ?
 
The other status indicators are all solid green, and as far as the robot controller, we've got errors on there that we are working on as well. There is an error for the flex i/o driver used on our robot controller, but as to which side is responsible for the error, we are unsure. There is no I/O on the robot side of things, they only change state on the flex I/O module.
 
How are you connecting the Flex I/O to the Kuka controller ?

Are you connecting to the MFC?
Have you used a terminating resistor?
Check the devnet.ini file and make sure it is set up for the correct number of nodes.

Have you re initialised the I/O drivers recently?
 
Last edited:
Programming

Please remember that the 1794-ADN adapter needs to be programmed for you to read the right IO-table from your "subnet" under the ADN.
Not sure if the ADN will present all the data from your IO cards without programming it. It might have default mapping that you can use if you know it

That was my experience with the 1794-ADN, connected to a SLC devicenet scanner.... that the node had to be programmed/configurated itself
 
Also remember that the Kuka controller expects (assumes and demands) to be the "master" on devicenet and this is non negotiable.

And for those of you experienced with Kuka robots - yes I know there are ways around this but it's easier to let the KRC have it's own way! Trust me, it makes for an easier life when trying to troubleshoot the devicenet later on in it's life.
 
We got everything up and running, turns out there was a bent pin between our input module and the 1794-ADN which explains why it wasn't working. And our driver on the robot needed to be reconfigured. Robot is funtioning properly, and so is I/O. It's always the little things, thanks to you all for the help. :)
 

Similar Topics

Got this new to me powered on today and have no main air and the only problem I have found is the f059 on the vfd. S1 has 24v, none on S2, and 48v...
Replies
10
Views
468
Greetings everyone, I know there is a way to programmatically set the date/time on a 750 series VFD (look up Rockwell automation sample code)...
Replies
1
Views
1,041
Hello friends, I preferred to make a new post because the subject is not the same and I will see in time if my situation is good to put the old...
Replies
10
Views
2,538
Can someone do me a huge favor and print these 2 Allen Bradley DNO files and email them to me? [email protected]...
Replies
1
Views
1,751
Hi all, Client with a pretty much brand new AB Powerflex VFD starting throwing Fault 17: Input Phase Loss this afternoon. Started doing some...
Replies
6
Views
9,463
Back
Top Bottom