BRX Series PLCs (Stackable Micro Brick) Videos

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