INTRDEF

[Lorne Van Dusen]

I know that this may sound like a dumb question but I would just like some clarification
During the First Scan
If I want to call Interrupt #3 on the Rising Edge of Input 3 I would use INTRDEF 3,3,1
Can I then use INTRDEF 3,18,0 to call interrupt #18 on the falling edge of input 3

[garysdickinson]

Lorne,

The answer to your question is no.

A specialized interrupt INPUT can only respond to either a rising edge or a falling edge event, not both.  If you issue 2 IntrDef statements for the same interrupt channel:

IntrDef 3,ISRPosEdge,1
IntrDef 3,ISRNegEdge,0

Only the last IntrDef statement would be active.  

If you need to respond to both the positive and negative edges of a signal, you will need to route this signal through 2 separate Interrupt input channels and setup one channel for positive edge and the other for negative edge responses:

IntrDef 3,ISRPosEdge,1
IntrDef 4,ISRNegEdge,0


Please note that the documentation for the IntrDef statement is slightly incorrect.  I have added some text in RED to correct the documentation:


INTRDEF ch, fn_num, edge
Purpose
Enable Interrupt Input channel ch.
ch = interrupt channel number (pls refer to PLC installation guide)
fn_num= Custom Function name or number to execute when interrupt pin changes according to the defined edge. This is the Interrupt Service Routine ISR.
edge = Positive number means rising edge-triggered. 0 or negative number means falling-edge triggered.

At my urging, I have gotten TRI to allow the use of the name of the custom function as well as the number of the CF for the 2nd argument.  I would suggest that you only use the name of the custom function as it is both more readable and it is safer.  

Why do I mention safer?  It is possible to change the number associated with a custom function by shifting functions up and down in the "I/O Table" definitions.  If you use the CF number and shift the CFs around in the table the WRONG CF will be executed as the ISR and your code will not function as you had intended. If you reference the CF by name, then the code should compile and execute as expected, even if you re-arrange the CF in the "I/O Table".

Best regards,

Gary D*ckinson

[Lorne Van Dusen]

As always Gary thanks for your well descriptive reply.
I am glad I decided to ask that question as I wasn't sure if I could do both with the same input.
Luckily I have input 4 clear to use.
That means I can tie both inputs 3 & 4 together and use input 3 for the rising edge and input 4 for the falling edge.
I am also pleased to hear that we can use the symbolic name in place as the number because you are 100% correct in your statement. Sometimes after finishing up a program I like t go around and clean things up like get rid of stuff I no longer need and yes many times move or shift things up to fill blank spaces where I had deleted unwanted functions.

[garysdickinson]

Lorne,

The use of interrupts can be tricky.  

If your goal is to respond quickly to some external event by changing an OUTPUT, the response time is dominated by the ladder logic scan rate.  The OUTPUT will not change until the end of the scan.  In thus sort of scenario, it often makes more sense to just handle the input with ladder logic.

If you have an external INPUT that wiggles at a rate greater than you can handle with ladder logic, and you need to count each wiggle, I’d suggest that you look at using the specialized high speed counter system.

In any case, I strongly urge you to build a test system to throughly exercise and test your PLC firmware.  For most of my clients, I use a second PLC to model their system.  I typically model analog signals, Modbus devices, pulsatile inputs and many other things.  

You can model high speed digital pulses using the stepper motor or PWM SYSTEM. This is what I use.

If your system's response to these interrupt inputs is critical and the failure to respond could result in Catastrophe, please test the snot out of your code.  Make certain that your code can handle input rates significantly higher then the actual system can generate.

Best regards,

Gary D*ckinson

[Lorne Van Dusen]

Gary
Just to let you know that with the problem I was having with the interrupt actually turned out to be a power supply problem.
We use a low cost switching power supply to feed all the switches etc that go to the inputs of the PLC.
I monitored the power supply and found out when relays on the controller were changing state either on or off I would get a very short spike coming from the power supply. And when I used the input as an Interrupt the PLC actually reacted to the extremely fast spike.
I then changed the program and did bth the rising edge detection as well a the falling edge detection in Ladder and it solved all my issues.
It seemed that the extra scan time involved in the Ladder program prevented the microprocessor from seeing the fast spike in the line.

However I do have a question that hopefully you can answer is there any way to find out the scan time of the PLC. Most PLC manufacturer have a value that you can look at that actually tells you how long the scan time is.

lorne  

[garysdickinson]

Lorne,

The scan time of the PLC is not a fixed rate.  It is dependent of a number of things, including:

• The number of I/O ports that the PLC is supporting.
• The size and complexity of the ladder logic program that you created
• The amount of time that the ladder is suspended waiting for your custom functions to execute.
• The overhead of the PLC low level firmware.
• Are you using online monitoring for debug.  On-line monitoring is constantly "talking" to the PLC low level firmware to get data to display.  This takes time.
• And a bunch of other stuff...

The maximum scan rate that the Fx (Smart Tile) PLC can achieve is surprisingly fast if your PLC program is trivial.

There are a couple of things that you can do to monitor the scan rate of your program:
1. Add ladder logic that toggles the state of an OUTPUT on each scan.  You can monitor this pin using an oscilloscope or logic analyzer.  I have attached the ladder logic for this approach.
2. Add a CF that is invoked on every scan of the ladder logic.  This CF records the current CPU time and on each subsequent call will calculate the time between scans.  You can keep track of the min, max and average scan times.   The function, STATUS(21) returns a 32-bit number that is in the units of 0.1us.

You put this sort of code in a CF that is called on every ladder scan:

A = Status(21)   ' current CPU time
C = ABS(A - B)    ' scan time in C, 0.1 us units
B = A                  ' save current CPU time for next call to this CF


I hope that this is useful.

Best regards,

Gary D*ckinson