Announcement

Collapse
No announcement yet.

Interrupt capability in Productivity PLCs

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts


  • Interrupt capability in Productivity PLCs

    Helping out another member today got me wondering, why doesn't the Productivity have the ability to do an interrupt? It is so powerful in many others ways, yet it doesn't have this basic ability that PLCs have had for decades.
    The Call Task instruction will sort of do an interrupt as when the ladder scan reaches that, it will jump to whatever task it calls, run that task, then exit and jump back to the line it left off at in the main ladder task. But why cant we have an actual interrupt thats we set up outside of ladder that will cause a halt to the ladder scan and then run whatever we told that interrupt to do? Have the interrupt either be set up to run at a specific time interval (down to the tenths of a millisecond), or it a certain combination of tags is met like the Input Events interrupt of Do-More.
    Since this is outside of ladder for how it runs and gets configured, maybe make a new tab in the CPU hardware configuration where you configure the interrupt or disable it from being used at all. Once you set the trigger condition for the interrupt, then you select what it does in the configuration. Either call a task, or set on a specific output, or reset a specific output. Perhaps even allow a couple interrupts rather than just 1.
    Is this something that can be enabled in the hardware?
    Last edited by MikeN; 10-03-2018, 03:30 PM.


  • #2
    During initial development of the Productivity Series plc I believe the thought was that scan time on the plc was so much faster than older plcs at the time that interrupt capability would not be as important. (I was not involved at that time so not 100% on why the decision was made.) We have discussed adding a software interrupt option. At this time a hardware interrupt is not an option since all I/O must go through backplane messaging. We are also looking into designs that would have some I/O built into the CPU PCB so we could have hardware interrupts.

    Thanks for your comments and suggestions as we try to advance the Productivity Series.

    Comment



    • #3
      PSeries_Eng, you mention that the backplane messaging makes hardware interrupts not an option. So what is time delay and/or dither assoctiated with the backplane messaging? What I mean is, given a rising edge on DC discrete input , what is the expected time it takes before the cpu would be able to see the off/on transition and act on it?

      Comment



      • #4
        Originally posted by g.mccormick View Post
        PSeries_Eng, you mention that the backplane messaging makes hardware interrupts not an option. So what is time delay and/or dither assoctiated with the backplane messaging? What I mean is, given a rising edge on DC discrete input , what is the expected time it takes before the cpu would be able to see the off/on transition and act on it?
        Can't speak for PxK's backplane specifically, but in general, a backplane has to be specifically designed to accommodate pushing data to the CPU, rather than the CPU pulling. Which isn't to say it's a hard thing, it really isn't, but if it wasn't designed that way it can be difficult to add after the fact. When Host designed the original H2/T1H Do-more controllers, we were unable to do interrupts due to similar constraints. We explored the possibility of using hardware to poll for 'interrupts', but like the PxK engineers, decided that our scan was fast enough that it didn't matter.

        One of the very liberating aspects of designing BRX was that we had I/O going directly into the CPU, which made it possible to do some nice things that traditional backplanes prevented. Since 95%+ of apps don't need that type of capability, it isn't a deal breaker for most. But for those few, single digit microsecond response times can be the difference between a fast machine and a useless machine, since the usual fix is to slow the machine down until tolerances are acceptable.

        Comment



        • #5
          So what is time delay and/or dither assoctiated with the backplane messaging?
          As BobO the I/O can't interrupt the scan across the backplane since it cannot push data to the cpu. In general the Inputs update in microseconds. However, how long it would take depends on several variables. Scan time being the biggest.

          Comment

          Working...
          X