Author Topic: PLC INPUT Interrupt Behavior  (Read 22983 times)

garysdickinson

  • Hero Member
  • Posts: 502
  • Old PLC Coder
    • View Profile
PLC INPUT Interrupt Behavior
« on: October 05, 2022, 03:12:18 PM »
I have been working on using the INPUT interrupts that are tied to end limit switches for a stepper based motion system.  I have gotten them to work, but am a little confused about the timing.

This is the code for one of the ISRs:


' Ch1LoLmtISR - Interrupt handler for Ch1LmtSwLo
'
' This code aborts the CH1_Y stepper system when the interrupt condition is met
'
StepStop CH1_Y          ' Abort Stepper Motion
IntrOff Ch1LmtSwLo_Int  ' Disable interrupts for this Input
SetIO Ch1Intr           ' Set ISR event RELAY


I am aware that while an ISR is active, following the execution of IntrDef, that the INPUT pin status is NOT latched at the end of the ladder logic scan. When the ISR for an input is disabled, the INPUT status is "visible" to ladder logic.  So my "initial fix" was to re-sych the Ch1Intr RELAY at the end of the ladder logic to control a 2nd RELAY, Ch1IntrDly, with something that looks like this:

Ch1Intr
----||-----------------------------------------(Ch1IntrDly)

My assumption is that if the ISR set CH1Intr then waiting one scan time the delayed version of CH1IntrDLY in ladder logic, that the physical INPUT would be visible to the ladder logic.

Sometimes this works and sometimes it does not.  So I added more logic to delay the CH1Intr by a 2nd scan and this worked a bit better, but sometimes failed.

Ch1IntrDly
----||-----------------------------------------(Ch1IntrDly2)

Ch1Intr
----||-----------------------------------------(Ch1IntrDly)

My "ultimate" fix was to make Ch1IntrDly a TIMER and not a RELAY. This will result in multiple scan times before the TIMER goes off.  Now everything is visible to the ladder logic.

Do you have any suggestions on a better approach to "know" when the INPUTs are working after turning off an INPUT interrupt?

Is there some other timing issue that I am missing?

Does the SetStop take a lot of time to execute? If so should I have rearranged the order of the lines of code in the ISR?
Does the IntrOFF statement take effect immediately, or is it delayed to some point in time that is tied to the ladder logic scanner?

Beat regards,

Gary Dickinson

garysdickinson

  • Hero Member
  • Posts: 502
  • Old PLC Coder
    • View Profile
Re: PLC INPUT Interrupt Behavior
« Reply #1 on: October 06, 2022, 09:42:05 PM »
I wrote some test code to see if I could figure out how long it takes from the time that an active INPUT ISR is turned off via the IntrOff statement to when the state of the physical INPUT can been "seen" by ladder logic.

The amount of time is 2 to 3 scans of the ladder logic. In most cases it takes 2 scans.

I have attached a image of the ladder logic and the complete program for the test to this reply.

The CF, Ch1FndLowSw sets up the interrupt for the INPUT[1] and issues a StepMove command.  The RELAY, GO, will invoke the CF.

The ISR CF, Ch1LmtSLo_Int, will be triggered when the INPUT[1], Ch1LmtSwLo goes active. The ISR is configured to respond to a rising edge event.  The ISR does two important things:
1. Turns off the ISR
2. Sets the RELAY, Ch1Intr to indicate that the interrupt has been serviced.

The CF, IncScanCount increments the TBASIC variable A on each scan of the ladder logic that the CH1Intr RELAY is active.

The PLC code is very simple.  Just complicated enough to answer some of my questions.

Best regards,

Gary Dickinson
« Last Edit: October 06, 2022, 09:50:16 PM by garysdickinson »

support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3174
    • View Profile
    • Internet Programmable PLCs
Re: PLC INPUT Interrupt Behavior
« Reply #2 on: October 09, 2022, 01:02:28 PM »
It is generally not recommended to use a digital input both as a general purpose D/I and an interrupt input at the same time by manipulating with INTRDEF and INTROFF especially if you need the D/I to function immediately within the next scan. Note that the interrupt is edge-triggered whereas the general purpose digital input is level-determined. The PLC firmware also deploys a software filtering mechanism to filter out what it deemed as "glitches" whereas when defined as interrupt input there is no filtering and that can also add to some uncertainty. For most PLC logic if the current scan misses the new input state change it is generally harmless to delay to the next scan to pickup the new input level.

My guess is that when the ISR is triggered the voltage level may still be midway between logic '0' and logic '1' but the edge transition has triggered the ISR to run and after you have disabled the input as interrupt it still may not reach the logic '0' or logic '1' voltage and hence is not picked up by the I/O scan (throw in some switch bouncing and that may further complicates the scenario). I hope that make sense...

BTW which specific PLC model are you using for this test?

     
Email: support@triplc.com
Tel: 1-877-TRI-PLCS

garysdickinson

  • Hero Member
  • Posts: 502
  • Old PLC Coder
    • View Profile
Re: PLC INPUT Interrupt Behavior
« Reply #3 on: October 09, 2022, 05:41:22 PM »
I am using the EZWire-1616.

I am using the edge triggered interrupts to terminate a stepper motion on the edge of a limit switch.  I am running the stepper at a very low step rate with no acceleration.  This way the StepStop command will stop the motion as close to the edge event as possible w/o the stepper losing position.

If I do this without using the interrupt system the the stepper can be 50 steps past the edge event as I am limited by the ladder logic scan rate.  Without using interrupts, I have to issue  a one-step motion command to detect the edge event.  These steps are limited by the ladder logic scan rate.  I can get 20..50 pps out of ladder logic.  My stepper hardware can run at 1000 pps and be stopped with StepStop without losing position.  ISR edge detection saves about 8 sections for each stepper based positioner.

If I had 4 additional INPUTS, I could wire 2 PLC inputs in parallel for each limit switch input.  This would get me both ISR and ladder logic visibility to the limit switches.  I will still have to disable the ISRs either by disabling them or substituting a non functional CF for those times when I don’t want the stepper system to be stopped on edge events on the limit switches.

    What how I think that the PLC handles INPUTs and INPUT interrupts:
    • Physical INPUT states are scanned and registered once per scan of the ladder logic. If an INPUT is acting as an interrupt source it’s valve when viewed by ladder logic is always 0, independent of the voltage on the INPUT pin.
    • INPUT interrupts are handled synchronously to the ladder logic scans.  I believe that these are handled directly by the PLC’s CPU. My ISR sets a RELAY to indicate that the edge condition was detected. My ISR, also turns off the INTERRUPT system for the the INPUT before exiting.
    • Ladder logic contacts, INPUTS included, can be differentiated or edge sensitive.  To detect an edge requires 2 successive scans of the ladder logic.
    • I suspect that it takes 2 full ladder scans to get the INPUT state correct after an INPUT interrupt is turned off. But because of the asynchronous behavior of the ISR, it may take a 3rd scan of the ladder logic to get the INPUT working.  My test code counts the number of scans from when a rising edge ISR runs until ladder logic detects the the INPUT is non-zero.  This code sees 2 full scans for about 9 out of 10 tests and 3 scans about 1 out of 10.

    I don’t think that I am observing contact or switch bounce.  I disable the ISR in the ISR routine. I would like to believe that your system level code would disable the CPU ISR before the PLC ISR code exits. Even if the ISR executed 2x, the PLC code will see only a single event from the ISRs.

    I believe that waiting 3 scan times following the ISR detected edge event will allow the PLC INPUT logic to return to "normal" (digital filtering is working), differentiated INPUTs working, …

    As you know, I am just guessing how the PLC operates. I am just picking your brains to see if I am missing something.  I appreciate anything that you can think of.

    Regards,

    Gary Dickinson


support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3174
    • View Profile
    • Internet Programmable PLCs
Re: PLC INPUT Interrupt Behavior
« Reply #4 on: October 14, 2022, 01:44:07 PM »
Hi Gary,

Thanks for the details explanation of your setup.

One thing about the particular CPU chip family that is used on Fx, FMD and Nano-10 PLCs is that the interrupt input operates using the "input capture interrupt" mechanism and due to the CPU chip hardware limitation, when used in "input capture interrupt" mode the logic level on the input pin cannot be reliably read by the firmware. Hence when a digital input has been defined as interrupt input (especially for input 1 to 4) the pin logic state are no longer visible to the ladder logic. This is due to chip hardware limitation that could not be overcome by the firmware. When you INTROFF an input pin inside an ISR , it will be reset to become a general purpose input again.

The general purpose input logic state are only updated during the I/O scan which normally occurs only at the end of the ladder logic scan. or after running a REFRESH statement. So right after your ISR has disabled the input interrupt, the digital input status will not change regardless of the actual physical voltage level. At the end of the ladder logic scan the I/O scan routine is the one to update the the physical input but the software filtering may yet filter out the new state and therefore requires another scan before the new logic state is finally determined.

The new Wx100 CPU is different in that the actual logic state of the physical input is still visible to the firmware when it is being defined as an interrupt or a HSC input so I believe your experience with Wx100 CPU should be different.

Email: support@triplc.com
Tel: 1-877-TRI-PLCS

Lorne Van Dusen

  • Jr. Member
  • Posts: 93
  • I'm a old guy
    • View Profile
Re: PLC INPUT Interrupt Behavior
« Reply #5 on: November 03, 2022, 12:58:40 PM »
Gary
I think you have the right idea but you are over doing it.
Leave the Interrupt as a Rising Edge trigger then in the first line of the function disable the interrupt then do a REFRESH of the IO then do a TESTBIT of the input you want then you can set any relay you want or reset any counters etc.
Then before you exit turn the interrupt back on.
Then in your ladder logic you can reset the relay you set in the function any way you want

garysdickinson

  • Hero Member
  • Posts: 502
  • Old PLC Coder
    • View Profile
Re: PLC INPUT Interrupt Behavior
« Reply #6 on: November 07, 2022, 01:34:35 PM »
Lorne,

I think your approach is reasonable. 

The feedback that I got from TRI is that the behaviors vary by PLC family. 

1. The Wx100 is based on a very different processor and the state of the physical INPUTs may continued to be visible to ladder logic while being used as an interrupt source. This is not the case with Fx based PLCs or the older FMD based PLCs.

2. There is some sort of debounce logic on INPUTs to filter out bounces that show up with mechanical contacts.  This mechanism is turned off for those INPUTs that are being used as INPUTs on some PLC  families.  The debounce mechanism is be based on ladder logic scan boundaries and may require more than a single scan to get settled.

The bottom line is that it can take one or more full scans of the ladder logic on most PLC families from when an INPUT interrupt is disabled until that INPUT's true state is visible to ladder logic.

Thanks for helping me think through this stuff.

Gary d






Lorne Van Dusen

  • Jr. Member
  • Posts: 93
  • I'm a old guy
    • View Profile
Re: PLC INPUT Interrupt Behavior
« Reply #7 on: November 08, 2022, 07:01:28 AM »
Gary I had had a similar issue and when I did some detailed testing I discovered that there was a 24VDC relay that was connected to a PLC output and the manufacture of the equipment forgot to install a diode across the coil. Be-leave it or not that spike created cause the PLC to call my interrupt that I used to reset the HSC value. 
I found out with some help from tech support that within the interrupt I could disable the interrupt then I could do a quick Refresh and read the input that was tied to the interrupt which now is at level logic then reset my HSC value then re-enable the interrupt . All this added less than 1ms which actually prevented the spike from resetting the HSC and was still more than fast enough to reset the HSC value instantly.