https://www.automationdirect.com/brx (VID-BRX-0004)
BRX Inteerupts can be triggerd at regular intervals or even used in a one-shot mode. Watch this tutorial to learn how!
Our FREE Practical Guide to Programmable Logic Controllers eBook: https://www.automationdirect.com/ebooks/plc-handbook
The Do-more BRX PLC has four built in timers you can use for interrupts. Why is that important? Well, Remember that a PLC reads the inputs at the top of the scan, executes its ladder logic, then updates the outputs at the bottom of the scan. If we toggle an output bit every scan it would look like this on most scans, but on some scans it might take a little longer – it all depends on what the ladder logic is doing during that particular scan. And that’s the key point – we never really know exactly when those outputs are going to be updated. So what if we wanted generate a regular periodic output that wasn’t affected by the scan timing? Or what if we want to add a known delay to an output and not have it affected by the scan time? Well, that’s where timer based interrupts and the immediate out instructions come in handy. Let’s do an example to see how that works. Let’s setup a timed interrupt, make it recurring, with a duration of 250 microseconds, and create a new ISR to handle that timer generated interrupt event and hit OK. So now, every 250 microseconds – regardless of the scan time - this ISR will be executed. In that ISR, let’s toggle output Y0 so we can see it on a logic analyzer. Notice that we’re using an immediate instruction to toggle Y0. That says set this output immediately – don’t wait for the bottom of the scan when outputs normally get updated. Accept all of that. Make sure the PLC is in terminal mode. Write it to the PLC. Switch it back to RUN mode. If we look at Y0 on a logic analyzer we see our 250 microsecond pulses coming out. And look how rock steady they are. And remember – we don’t have any ladder code in the main loop do we? This runs completely independent of the normal scan. In fact let’s try that. I’ve created a little ladder program that uses a timer to enable a task every millisecond and also resets the timer’s accumulator so it will start counting up again to 1 msec. The task, just increments a register a thousand times to waste some scan time. I’m also toggling Y1 each scan using this Scan Toggle bit which inverts every scan. That will get updated at the bottom of each scan just like all the other normal outputs. So we should see Y1 toggle at regular intervals, except on the scans where the task is enabled which will make the scan take a lot longer. Now if we look at those outputs on a logic analyzer, we can see Y1 toggles every scan and some scans take a lot longer than others when that task gets enabled. But Y0 – which is toggled by the interrupt timer event - toggles at regular intervals completely independent of the scan time. Again, exactly what we expect. So now you have a way to generate super accurate outputs that are independent of the scan time. How cool is that? If you need to disable that timer interrupt, you can either use the ISR structure member to inhibit that in code, or, just go back to the dashboard, click on interrupts and uncheck the enable box. That interrupt event is now disabled. The immediate out instructions are really intended to be used in ISR’s but you can use them in your regular code if you want to. For example, let’s clear out the previous example and use the immediate instructions in the main program to set and reset Y3. What would happen if these were regular out instructions? Well, since outputs don’t get updated until the bottom of the scan, all we would ever see would be the result of the reset instruction and Y3 would never change. But in this demo we’re using the immediate instructions. Let’s see what happens. Accept all of that. Switch to terminal mode, write the program – notice Do-more Designer is warning us that we are using immediate instructions outside of an Interrupt Service Routine – we know that so we hit ok. Sure enough, we see Y3 toggle – it gets set and reset during each scan – it doesn’t wait for the bottom of the scan to get updated. Cool. Looks like it takes a couple microseconds to do that, but look at this - the scan takes about 280 microseconds. Why does the scan take so long if all we are doing is toggling a bit? Because there’s a bunch of stuff the PLC has to do at the top of a scan, including reading all the inputs and a bunch of stuff it has to do at the bottom of the scan including setting the outputs. Regardless, half a millisecond for a scan? That’s pretty good. So far we have been using the timer to generate periodic interrupt events independent of the scan time. Can you use the interrupt timer to generate just a single super accurate delay? Maybe you want something to happen sometime after an event occurs and it needs to happen right away, and not wait for the end of scan. Easy, just use this one shot mode. The interrupt event will trigger one at the delay time you specify. Easy. If you have any questions about the BRX PLC please contact AutomationDirect’s free award winning support team during regular business hours. They’ll be happy to help. And don’t forget the forums. There are lots of folks there that love to share their years of experience. Just don’t post any questions directed at AutomationDirect’s support team there – they don’t monitor the forums on a regular basis.
Voted #1 mid-sized employer in Atlanta
Check out our
job openings