Possible to fix scan times in slc/o5?

Is it possible to fix(set) the scan time in the slc/o5?

Thx

I've never tried this so use it with a little bit of caution.

To the best of my knowledge there is no way to fix the base scan time of the SLC5 line. However, you might be able to cheat.

Ladder file 2 is the only file that runs cyclically. Instead of using ladder 2 as your 'main' ladder, use ladder 3. Program it just like you would ladder 2. Then make ladder 3 your STI file. Just make sure you set the STI time (the time between STI calls) long enough so you don't call an STI while the previous one is still running.

Like I said, I've never tried this but theoretically it should work.
My question is why do you need the fixed scan time? There may be a better way to achieve your goal (whatever that is) than to run a fixed scan time.

Keith

I've written my own PID code and to keep the I and D coefficients universal across controllers they have to be time compensated.

I am not sure how well this will work on an SLC but I have used a fixed scan time on Mitsubishi A Series PLC's to provide an accurate timebase when calculating the frequency of a pulse stream. If the scan time is set so that there is a guaranteed gap between the end of one scan and the start of the next and the code for the calculation is placed at the start of the programme then this is far more accurate than using timers.

Yes Andy, that's essentially what I'm trying to do. If there's not a way to fix the scan I'm thinking I might use the current scan value in the status file but I don't know if the value is;

a. last scan time.
b. scan time to now.
c. scan time to expected end of this scan.

Jim:

Ketih's method will work, but you increase the potential of the PLC not being able to finish the first STI scan before the second one begins (= bad).

Instead of forcing the ENTRIRE slc to have a fixed scan time, just put your PID block (and I/O update, if needed) in a single program file, and set up that file as an STI.

This is the way the SLCs are supposed to handle PIDs (and why they have an "STI" option for update time rate).

See the help files for more information.

The one millisecond resolution scan time is the scan time from the previous scan. Like Andy said, if you put the calculation as the first thing done in the scan the last scan value will be pretty accurate.

If you are using an analog input as the source of your data make sure you get an updated value every scan. The analog conversion rate on some of the inputs can be a little long.

If you need to wait more that one plc scan for the analog input conversion you can use the STI just for the calculation. Make sure you do an immediate input (IIM) of the channel you want to use before you use it.

Hope this helps.
Keith

OK, it looks like the STI cmd is the one to use. One question, can the interrupt time be longer than the scan time, ie. scan time 10ms and interrupt time 25ms?

Thanks a million.
Jim

A PLC is "single threaded". It can only do one thing at a time. STI execution trumps "regular" scan.

There are two times that you have to worry about with STIs, only one of which you have direct control of.

The interrupt time (aka setpoint) is the time is the time BETWEEN interrups. There is also an amount of time that the PLC will take to execute the STI.

If the interrupt time is less than the STI scan time, you have a problem, because the STI logic won't finish before it's supposed to start again.

If the interrupt time is only slightly longer than STI scan time, then there will be very little left over for use to execute the regular program.

But it sounds like you want to execute the STI less frequently than the remainder of the program takes to scan. This is fine. The regular logic can execute many times (and be someplace in the middle of scan) when it's time for the STI to do its thing. When its thing is done, the regular scan will continue from where it left off.

Thanks Allan,

Yes I want to execute the interrupt less frequently than the scan rate. The reason I ask is because the subroutine is executing at the scan rate rather than the STI settings. The subroutine is file #6. For test purposes I've set S:30 to 255, S:31 to 6. I'm under the assumption that with these settings file 6 would execute every 255ms. This is my first project w/AB so it's very possible I've missed something.

Thanks,
Jim

Jim-

Keep in mind that S:30 in in 10 millisecond increments. So a value of 255 will give you STI execution every 2.55 seconds.

Also, make sure you don't call your STI as a subroutine from the main program using the JSR instruction. The SLC5 doesn't limit execution of the file defined as the STI. So if you call file 6 (in your case) as an STI AND as a subroutine with a JSR, file 6 will execute in both cases, which is not what you want.

Keith

Keith, you got it! I was calling from both places. Thanks very much, you've saved me alot of time today.

In edit, thanks to everyone I really appreciate your time.

Jim

It sounds like Keith got you on the right path.

One adjustment to what he said - by default, S:30 is in 10 msec units. If you set S:2/10 (Resolution Select Bit), then it is in 1 msec units.

This allows for a range of interrups from 1 msec to 2.55 sec.

Thanks Allen, I did end up finding that bit which allowed me to get the 25ms period which I was looking for.

Regards,
Jim

lets just think about this...

Let us think that the PLC scan time is a process variable.

The measurement (the scan time register) is actually a
report of the 'previous' scan time.

Lets also say that you made your first rung in the program
capture this register, and average it for the last few
scans.

Now you have a non-weighted variable, and its just a little
delayed, but gives a better idea of the recent average
scan time.

We know (because AB tells us) that some output instructions
take a L O N G time to execute if they manipulate arrays,
use indirect addressing, or are just darn complicated.
We might even take a collection of these very long instructions
to manipulate meaningless data, and place them in an equally
meaningless ladder file.

So, then, we _could_ (if we wanted to get real fancy) write a PID instruction that looks at the
non-weighed recent scan time variable, and integrates up
(very quickly) an output that basically says 'how much scan
time to add'. This variable could be then used to call the
previously constructed program a 'set number of times' to
create the required addition to scan time.

(Of course, if this were a PLC-5, you could simply put the amount
of scan time to add into S:77, and you'd be done, but that's
not the question.)

The real question in my mind is: what does doing this get you?
As previous posters have opined, the STI is the hot set up for
repeatable computation timing, notwithstanding the ability of the
processor to deliver I/O data at a faster or more repeatable
rate.