Improve speed and/or accuracy??

[esp400]

Yep, two out of the three are. The LVDT and the load cell. I would think that allowing the STI to run all the time would create a ridiculous amount of interrupt latency. You use the STE and STD to create areas where the STI cannot occur to avoid this. This SBR is not called in the main program so it needs the interrupt to update the IIM's. Whoever created the file must have left it out for that reason I guess. I'm thinking about just moving the entire SBR#13 into SBR#6 where it is called with a cycle latch and putting it in the top rungs with the STE and STD around it to see if things get better.

 

[kamenges]

To the best of my knowledge you can't use an analog module to trigger an input interrupt. I think it need to be a digital module. So if you are trying to trigger the input interrupt on an analog value I don't think that will work.

I want to make sure you understand what the STI is. The Selectable Timed Interrupt functionality allows the user to specify a SINGLE file that is automatically triggered by the operating system at a user defined cyclic rate. You are allowed to place a JSR in the STI file and call other files from that location but I would be very careful with that. Also, the plc will allow you to program a JSR that jumps to the file designated as the STI file but that really defeats the purpose of an STI.

The STI functionality was really designed more for the process industry than anything else. It was a way to force a specific portion of logic to operate at a fixed call frequency; no faster, no slower. You are using it for a slightly atypical purpose, although it is valid for that purpose.

The STE (STI Enable) and STD (STI Disable) instructions will enable and disable execution of the file designated as the STI file. So those instructions will not affect "interrupt latency". They will likely affect the rest of your scan, however, if you are running a high STI cycle rate and have significant code in the STI file.

If you are doing to enable and disable the STI, you need to at least have the STI active all the while you are evaluating the force input. The IIM instruction should be in the STI, although I don't know if an IIM on an analog module really does anything; I've never tried that. You also need to check the conversion rate on your analog input module. It doesn't make any sense to run your STI any faster than that since you would just be looking at unchanging data.

I hope this helps some.

Keith

 

[esp400]

I am triggering the STI interrupt with the STE in SBR#13. The STE output is enabled when the cycle is latched in SBR#6. The STI enable bit will then be made and the STI SBR will run. While I agree that analog values will not run a DII, I am not attempting to do that.

Secondly, I am aware that the STI scans only one file and it is held in S:31. However, you can scan as many STI's as you'd like by using the STS instruction.

The SBR#13 is being used to dump the numbers from the LVDT and the load cell at specific times during the test. So SBR#6 fires the outputs to physically make the test happen and it also has limits for comparison, it gets it's info from SBR#13. The test is accurate to ten thousandths of an inch but typically I only see a band of around .007in. I'd like that band to be around .003 and I believe it is due to latency.

The STE and STD instructions will increase interrupt latency. For starters, there is latency between the time the setpoint timer is done and the STI begins. Also, if the STI is called at the same time the main scan is between input cards, the main scan will always win out and it will make the STI wait. If you had the STI enabled all of the time and you had like 10 input cards, you could easily see where this would be an issue.

I will look at the conversion rate for the analog card. I don't see why an IIM couldn't be used with analog input but I will check into it.

I really appreciate the feedback

 

[kamenges]

I don't understand what you mean by "STI zone" in post #12. There isn't an STI zone, like there is when using an MCR. The entirety of the STI fil is scanned when the STI time expires.

STI initiation is done at the processor firmware level. It occurs within 500 microseconds of the time expiration regardless of other occurrences in the program. The rest of the program can do nothing about this, unless you have programatically disabled the STI function. In fact, rungs in the main program will be interrupted mid-rung if the STI triggers. So if you let the STI run continuously there can't be any latency.

The SLC processor DII function requires the use of a digital input. Using it with analog modules would be pretty tricky since you would have to hit an exact analog value to get it to trigger. Analog conversion rates would make it relatively slow anyway.

What I think you want to do is have a very stripped down, bare bones STI file running as fast as you can get it to run. Start with an IIM of the analog data you are interested in, see if it needs to be saved, save it if it does and latch a bit if it is saved. In the main body of the program, process the results if the latch is set and reset the latch.

Keith

 

[esp400]

The STE and STD create zones where the STI interrupt CANNOT occur. If your STI is set to scan SBR#13 like mine is and within file #13 you put an STE and STD it will only scan within the enable and disable. The rest of the file will be untouched by the STI regardless of the fact that SBR#13 is the file number in the STI. The STE writes the "1" into the STI enable bit and the STD writes the "0" into the STI enable bit. While I agree that if you have no STE and no STD it will scan the entirety of the SBR, perhaps you want that to happen, maybe you don't.

From RS Logix 500 manual:

Interrupt Latency and Interrupt Occurrences​

Interrupt latency is the interval between the STI time-out and the start of the
interrupt subroutine. STI interrupts can occur at any point in your program,
but not necessarily at the same point on successive interrupts. The tables
below show the interaction between an interrupt and the processor operating​

cycle.

Note that STI execution time adds directly to the overall scan time. During the
latency period, the processor is performing operations that cannot be
disturbed by the STI interrupt function.
Latency periods are:​

•​

​

​

​

SLC 5/02 processors interrupts are serviced within 2.4 ms maximum.​

•​

​

​

​

SLC 5/03 and higher processors: If an interrupt occurs while the
processor is performing a multi-word slot update and your interrupt
subroutine accesses that same slot, the multi-word transfer finishes to
completion prior to performing the interrupt subroutine slot access. The
Interrupt Latency Control bit (S:33/8) functions:​

•​

​

​

​

when the bit is set (1), interrupts are serviced within the interrupt
latency time.​

•​

​

​

​

when the bit is clear (0), INTs are serviced per rung, slot, and packet
execution time.
The default state is cleared (0). To determine the interrupt latency with S:33/8
clear, you must calculate the execution time of each and every rung in your
program. Use the longest calculated execution time plus your maximum​

interrupt latency.

 

[RoTaTech]

I wrote a similar program a few years back to time a door latch switch for a car door latch, testing the secondary and primary switch position (you know, the one that tells you "Door ajar" vs. door closed.) I believe I used a SLC5/03

It used a Quicksilver servo drive/motor combination to move a striker in, and I had to time the off-on-off-on.

This was the entire test - more detailed than yours, but perhaps you can use some bits from it. I know I had to learn the DII instruction to read the timing of the switch.

Part checks.
-part seated, both power and manual. 8mm prox
-child safety lever off before test
-screw in power motor (12mm prox) on power, not present on manual
-mylar tab
-enterprise cylinder.
-latch seated in nest
-threaded rod in place and shows threads
-black cap in place on power, not present on manual
-lock rod check (this was installed on request by JH, but is jumpered out in the logic, as there is no sensor yet. The HMI flashes a lock rod message when beginning test, and will until the sensor is installed or the HMI message is removed)

Engage strikers.
- Look to see both latch (servo position)and front catch (optic)on after engaging. (Return striker frt catch will return home, latch should stay closed. if doesn't, fail part.

Locked door test: Fire outside release, should not release

Child safety function test: Unlock door then fire inside release, should not release

CS effort test: Engage child safety (turning off). - check that there is a minimum effort (load cell) required to flick the CS lever, and that the effort is not excessive (air pressure switch)

Inside release test: Fire inside release should open - check travel and effort of inside release (travel with LDT, effort by the programmed torque of the inside release servo)

Engage strikers, pull back check to ensure latch does not return (Latch servo) front catch will return home optic.

Outside release test: Fire outside release, check effort (load cell to check minimum, air pressure switch to ensure that the pressure is not 'cranked up') and travel (LDT) . Check that the latch and front catch open.

POWER ONLY: engage strikers, fire power release solenoid, check for motor current in range, strikers should release

if all passed fire date stamp buck/shuttle and date stamp. (return both)

WIN 126 SEQUENCE:
1) Clamp part

2) Part checks.
-power only for screw 12mm prox
-part seated, both power and manual. 8mm prox
-enterprise cylinder.
-all optical/vision.
-latch seated.
-child safety off (optic)

3) Detent engage for power only.(on latch end)

4) Engage strikers.
- Look to see both latch (servo position)and front catch (optic)on after engaging. (Return striker frt catch will return home, latch should stay closed. if doesn't, fail part.

5) Fire outside release, should not release

6) Unlock then fire inside release, should not release

7) Engage child safety (turning off).

8) Fire inside release should open.

9) Engage strikers pull back check to ensure latch does not return (Latch servo) front catch will return home optic.

10) Fire 0/S check the latch and front catch open.

11) if all passed fire date stamp buck/shuttle and date stamp. (return both)

12) if part fails for anything: lock in clamps, release clamps with reset button keyed reset to reset station.
- Check efforts where load cell (minimum) present & pressure sensor

 

[kamenges]

Originally posted by esp400:

If your STI is set to scan SBR#13 like mine is and within file #13 you put an STE and STD ...

So, to be clear, you put an STD and an STE in the STI file?? Putting an inhibit to calling a routine that you are already inside of seems a little strange to me. you can't inhibit a call that is already in progress. And if the STE is conditional and the STI routine exits you will never get back into it unless you trigger an STE somewhere in the main body of the program.

You would expect the STD/STE combination to be in the main body of the program. The intent of this instruction pair is to prevent an STI initiation if there is something occurring in the main body of the program that can't be interrupted by even the STI. You would hope this is a VERY short segment. Since the STI timer still runs while the enable bit is reset you can get the case of a deferred STI, where an STI is requested but because the STI enable bit is low the routine can't run. But again, an STI pair in the STI routine is best case useless and worst case catastrophic in terms of STI execution.

As far as latency is concerned, I really didn't think about S:33/8. In all the cases I've used STIs in SLC processors I have set S:33/8. Since I did it as a matter of course I didn't think to mention it to you. But even so, unless you have some really complicated rungs or some very involved module communications it really isn't going to affect you horribly. In your particular case the only time this would be an issue is if you were in housekeeping, an STI triggered and you wanted to get the analog values while the processor firmware was reading the same module.

Keith

 

[esp400]

Consider one SBR that is 50 rungs long and perhaps you want your STI to only run between rungs 7-11, 15-25, 30-40, and 45-50. This is where you would put the STE and STD instructions to turn on and off the function of the STI. If you don't disable the STI with the instructions and write the "0" into the STI enable bit, are you not running the STI all the time for the entire SBR regardless of where the scan is in the entire program? Isn't this the purpose of an interrupt, to interrupt the main scan and "go look over here" at the period that you specify? If you don't disable it, it's still looking. That's latency. This is why I favor the STI over the INT interrupt because the INT has no control bits and is on all the time. You can turn off the STI. Below from the instruction help section on STI.

1. <LI class=p-stepfirst>After you restore your program and enter the REM Run mode, the STI begins operation.
   <LI class=p-step>The STI timer begins timing.
   <LI class=p-step>At timeout, the program scan is interrupted and the STI is scanned and simultaneously reset.
   <LI class=p-step>When the STI completes, scanning of the main program file resumes where it left off.
2. The cycle repeats.

And for the STD:

When true, this instruction resets the STI enable bit and prevents the STI subroutine from executing. When the rung goes false, the STI enable bit remains reset until a true STS or STE instruction is executed. The STI timer continues to operate while the enable bit is reset.

 

[Doug-P]

This is why I favor the STI over the INT interrupt because the INT has no control bits and is on all the time. You can turn off the STI.

The hardware interrupt can be disabled - from the instruction set reference: Enter the DII subroutine file number in word S:46 of the status file. (See page
B–58.) A zero value disables the DII function.

 

[OkiePC]

The purpose of the STI is to run at very regular and predictable intervals. The interval time is almost always a constant that you set and forget. The STD and STE instructions are to keep it from occurring for a section of code that you cannot allow to be interrupted, or to disable and enable the STI routine for periods when it is not in use at all. If you use the STD and STE too much, you may essentially defeat the purpose of it.

If your STI interval is much shorter than your overall scan time, then it will run more than once during the overall PLC scan. If the STI interval is longer than the overall PLC scan, then the overall scan may occur several times before the STI routine runs.

I have used STI routines for totalizing values and once for an operation that needed to happen every 10ms no matter what. In the latter case, the main PLC scan was about 20 ms and the STI routine was about a dozen rungs optimized for fastest possible execution.

I did not go back and read the whole thread, so I could be wrong here, but if you are using the STI and then disabling it and enabling it multiple places in the main program, you might be shoving a square peg into a round hole...

 

[kamenges]

When an STI file will only run once per trigger. You don't have to worry about bringing it back from that call. the operating system does that for you. Based on your last reply it seems as if you think that once an STI file is triggered it stays there until you bring it back.

I think you are looking at the usefulness of the STD/STE pair in reverse. The reason you have an STI in the first place is so it executes on a regular basis. The only reason you would NOT want an STI to execute is if something more important than the code in the STI file could be occurring in the main body of the program. This should not be a normal event. In fact, in 25 years of doing this sort of thing I don't think I have ever had a case where I didn't want something to execute regularly that I took specific pains to make sure executed regularly in the first place. Not to say there aren't those cases. But they should be by far the exception not the rule. The way you seem to be using the STD/STE combination you in effect ties to the main program scan anyway since you would need to have an interrupt request from the STI timer AND you would need to be in a program section where allow an STI to execute. Assume, for example, that the processor generates an STI request at the beginning of rung 51 in the SBR you refer to. The STI file will not be allowed to run until you reach rung 7 in the SBR one the NEXT SCAN. Now THAT is latency. Latency is the time between the occurence of an event and the knowledge of or action upon that event. What you refer to below is more an issue of total scan time. But if what you really care about is handled in the STI file you really don't care all that much about what you total scan time is.

I want to make sure I understand your program structure. The way you are using the STI there should be almost no code in it. You are in effect using it as a high speed input scanner. It should trigger an analog input update, look at the value of the analog input and possibly perform a comparison on that input. You may also need to put your valve control output in there so you can stop it based on the input if needed. But that would be about it. Any additional code would simply increase the scan time required by the STI file and starve the rest of the program of processing resources.

Keith

 

[esp400]

I am enabling and disabling one SBR to be scanned by the STI. And I am using it to grab values from the LVDT and the load cell at specific points where my switch actuator is(moved by another SBR) and when the switch closes. The switch closing is captured on a DI but everything else is analog(positions that the load cell and LVDT are at Force vs. Distance criterium).

 

[kamenges]

You could use both the DII and an STI for this. The DII would probably give you the best response for determining the switchpoint. The only thing in the DII would be an IIM to get the analog values and two moves to store the two analog raw values. You can perform processing on the raw values in the main body of the program. There is no need to disable the DII since it only runs once on the switch trigger anyway. It doesn't cost you anything.

You will need the STI to determine the other two values. If you want to disable the STI you could do that any time the cylinder is not extending during your test. But any time the cylinder is extending you need to allow the STI file to run whenever triggered by the STI timer. In the STI file you would have an IIM that reads the LVDT position and the loadcell data. A logical combination of comparisons of those values would be used to determine when to save the force and position data. That is all that would be in the STI file to keep the scan time low. Run the STI at the fastest rate you can without getting a watchdog fault. You can determine when the test is aborted externally from the STI since all you are really worried about are the input values and not necessarily what the test is doing as a whole.

However, as I said previously, you need to find out what your analog conversion rates are on the input module as well as the analog update rates from the sensors as this will limit how fast it makes sense to run the STI.

Keith

 

[shooter]

or take an arduino better and cheaper.