Hide Transcript
View Transcript
The DoMore makes troubleshooting the Ethernet
I/O system simple. You just keep an eye on this guy right here
ñ thatÃs your DoMore Check Engine Light ñ if something goes wrong anywhere in your
Ethernet I/O System, this will be your first indicator. For example, suppose we have a bad Ethernet
connection right out of the Master ñ IÃm gonna reach down and pull the masterÃs Ethernet
cable ñ and sure enough the check engine light immediately turns RED. Well, I just click on that and it brings up
the system information which tells us at a 50,000 foot view that there is an issue with
the Ethernet I/O System ñ I just click on the I/O System View button, which is conveniently
colored RED to prompt me this is what I need to do next! That brings up the I/O System Monitor which
gives me a detailed view of the entire system, including the Ethernet I/O Master and all
of itÃs slaves. And sure enough, the Ethernet I/O master is
colored red and so are ALL of the slaves ñ thatÃs a pretty good clue that we have no
Ethernet communications ñ right? IÃll plug the Ethernet cable back in, the
DoMore automatically recognizes the issue has been resolved and turns off all the error
indicators ñ we are good to go! Now, what if an individual module in a remote
slave has an issue? IÃm going to disconnect the power to this
Analog module right here. This time my check engine light is a yellow
ñ a warning. What do I do now? Same thing ñ click on the indicator ñ brings
up our high level view telling us there is an issue with one of the I/O masters. An again this button is conveniently highlighted
to remind me thatÃs what I want to do next. I click on that, up pops my I/O system view
and I can see that this master, is reporting that this slave has an issue with this module. If I click on that module then over here in
the right hand pane, it tells me what module it is, what addresses it is occupying, and
there is an error message here ñ you can see it scanning through all the channels. ItÃs telling me every one of the analog channels
has failed. Well, thatÃs a pretty good indication that
something is wrong with the whole module. And of course in this case it is me, because
I disconnected the power. IÃll reconnect the power, and after the DoMore
has made sure all the channels are back on line, it automatically clears the warning
for us. Now what if I have a power loss at a remote
base? LetÃs remove the power from this Terminator
base. Well, same thing. Our check engine light lights up red, we click
on that, we get the 50,000 foot view telling us there is something wrong with the Ethernet
I/O system, we click on the button that is already highlighted for us, and we instantly
see that this master is reporting that this slave has got a problem. We click on that, and it tells us the slave
has a timeout error. The slave is not responding at all. So now we know that we need to go figure out
why that slave isnÃt talking to us. So how cool it that, whenever there is an
error in the Ethernet I/O system, you just click on the indicators and drill down as
far as you want to figure out what the issue is. Easy. Did you notice that when I unplugged the power
to the Terminator Slave, that the Master PLC got kicked out of run mode? What if you have a slave that is not critical
to the operation of your system ñ can you change things so that an error on that one
slave doesnÃt shut down the whole system? Sure. If we go back to Configuration, Ethernet I/O
master, and letÃs fix that terminator. Double click click on him. Look, right here I can say the CPU remains
in run mode on slave error. We can also specify that the slave has to
be ok in order for the master to be able to enter run mode in the future and what we want
to do with the inputs on error ñ I like to hold the last state so that I can go in and
see what they were doing when the system crashed. OK, well letÃs try this one. Again, if this slave crashes, the CPU should
remain running. LetÃs try that. IÃll say OK. I went ahead and plugged that slave back in
so there arenÃt any errors when we start. WeÃll say OK there. Write this new configuration out to the PLC. LetÃs go ahead and get the PLC back in run
mode. Remember ñ it got kicked out when we had
the error last time. I can see here that we are running and that
the PLC is ok. LetÃs go ahead and remove the power from
that terminator slave. And sure enough, we get an error, but this
time itÃs only a warning, itÃs not the red error- AND ñ the PLC is still running. Exactly what we wanted. LetÃs check the other condition. If I take the PLC out of run mode ñ heÃs
in program mode - and then try and bring him back, what happens? It doesnÃt come back. Remember ñ we selected that option on the
dialog that the terminator slave has to be fixed before the PLC will be allowed to re-enter
RUN mode once it has been taken out. So again, exactly what we expected. If I plug the power back into the Terminator
slave, wait for the error messages to clear, and now try to put the PLC back into run mode,
it works exactly as expected. Perfect. Note that while we have been using the DoMore
Designer to do all of this debugging and diagnostics via the check engine light, you can also do
it programmatically. There is a new Ethernet Master Error flag
that is I basically the status of that check engine light. There is also this Ethernet I/O Master structure
which has this general error flag too. ItÃs very similar to this EthMasterError,
but just to be sure I donÃt miss anything I check both, and if either one is active
I go ahead and launch some kind of Ethernet I/O Diagnostic program. That program would then walk its way down
through this structure, and use that information to figure out where the error is in the system. These are all the same bits that are driving
the RED and YELLOW stuff we saw just a moment ago. So you can do the same kind of stuff we did
back there but in your ladder code. How about that? One last thing to keep an eye on is the polling
rate of each slave. If the slave is not a high priority, then
consider slowing down the polling rate to open up the Ethernet bandwidth for other devices. How do you do that? Easy. Go back to configuration, Ethernet I/O master,
click on the slave of interest, and right here you can set the polling rate to anything
you want. This slave is not a high priority for me so
I have it only updating once a second. Now, if you want to see whoÃs using all the
bandwidth and how each slave in your system is doing, then check out the Ethernet I/O
Monitor. You can reach that under the debug menu, Ethernet
I/O Monitor. In this dialog you see the general Ethernet
statistics for the entire system and what each slave is doing. Remember ñ we set the Terminator IO slave
update once per second - right? WeÃll look ñ we can see that right here
ñ these guys are updating like crazy, this guys is only updating once a second. You can also see retry counts and configured
retries, last error code ñ all of which were generated back when we unplugged that module,
of course. And then over here you can see the rate you
specified for each module. This guy is specified to update once a second. These guys are specified to go just as fast
as they possibly can. If I pull an Ethernet cable on one of them,
we can see the error right here. Put it back, the error clears. And if we want to restart the error codes
and the counts, we just click on these buttons here. Nice. You can even go straight to the I/O System
view, the Ethernet I/O monitor or copy all of these statistics to the clipboard so you
can e-mail them to a co-worker or even tech support. Be sure to check out the other DoMore videos
in this series for more ways to get the most out of your DoMore system. And donÃt forget ñ If you have a question
you can reach AutomationDirectÃs free support via phone, e-mail, and live chat during regular
business hours. Spend LESS. Do MORE. From Automation Direct
Safe &
Secure
Updating...