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