Control Logix scan time...

First off i will say i love programming the control logix..The tag based programming makes it a dream.. For those who dont know i come from a modicon backround with AB 100 training..Yep the old traffic cop..outputs were 0001 and inputs were 10001 etc etc.. I finished my last project on control logix and do like the hardware..It has lots of fuctions that were bulky in modicon and love the fact that you can do both FB and ladder in the same program.

Now to the question..

There are few people out there who have used these in process applications...whats the scan time?? I will post mine after i have some comment so i dont get the "thats good time" comments..

why??

I feel my scan time is to low..my program relies on a resolver heavily!! and after i do the math the resolover is changing postion to quick for the scan time..Ie. turn output x on at 360degrees..however when the resoolver is reading 360 degress the PLC "Missed" it and i have to program 360-363 or so...

Just wondering if my scan time is out to lunch becouse of the way i programmed?

BTW the main lader diagram id 250 rungs the addition routine is 50 rungs long (All multiplication)and runs in parallel to the main routine..I also have 2 other routines that only run as required and stop the main routine when they run..The main routine is mostly "if a=><B then C" or "if a=(b+360) and <> C then D"..in other words it math orientated..

I thin i may have screwed myself with the tags..eg. tag is "Line_1_infeed_start_button"

It makes for great documentaion but what does this do to the processor speed?

For clarification my set up is as follows

10 slot rack (primary)
6 slot rack (remote over ethernet)
PV+ (Over ethernet)

Tag-Based programming has been around for about... oh... 20, 25 years or so.

My first exposure to it was on DEC (Digital Equipment Corporation) Computers using VMS (Virtual Memory System).

The "C" language has been tag-based for all of it's life (a little less than 25 years).

One of the main features of tag-based names is the length of the name.

Way back when, the names were limited to 8 alpha-numeric characters. Then they were 16, then 32... I wouldn't be surprised to see that there are 64-character tags now.

As far as having an impact on processing time, it depends...

One byte can be loaded into an 8-bit processor register in one fetch sequence.

Loading two bytes into a pair of registers in an 8-bit processor takes two fetch sequences.

If the processor and bus width are the same as the nominal tag width then loading can occur in one fetch sequence. Otherwise, a full fetch sequence consists of as many steps as necessary to complete the fetch.

Typically there is an optimal width with the capability of handling larger, less optimal widths. It all depends on the internal Memory Management scheme.

However, in general, this issue shouldn't cause a heck of a lot of grief in your process scan time. With respect to your encoder issue, you probably need to look at your implimentation. You might need to design in some flexibility with a self-correcting feature.

On the otherhand, it might also be a simple case of the wrong tool for the wrong job.

darrenj said:

I feel my scan time is to low..my program relies on a resolver heavily!! and after i do the math the resolover is changing postion to quick for the scan time..Ie. turn output x on at 360degrees..however when the resoolver is reading 360 degress the PLC "Missed" it and i have to program 360-363 or so...

Click to expand...

I don't know ControlLogix and cannot tell you how to find out your current scan time. I am sure someone will point you to that direction.

However, as a general observation, you cannot expect to be able to detect 360 degrees, or any other position, precisely - unless your resolver runs extremely slow or has very low resolution. In applications like that, there is always a detection window. It seems like 3 degrees is OK in your case; for most of my machines I have to put up with 10.

What is the maximum RPM of your resolver axis? How many counts per rev does the resolver module provide? Those are the answers you need to know in order to see if you have a problem. I would add one more: how critical for your aplication is the 3 degree position error you are having - is it really a big deal?

If you are pursuing some kind of positioning accuracy, you have to consider fixed scan time (once again, I am not familiar with CLX, but I think it has such an option). Normally, PLC scan time varies, depending on the amount and type of logic to be executed. In this case you simply cannot predict or determine how many resolver counts you would be able to detect from scan to scan at 100% rated speed, since there would be 2 or 3 or 5 or maybe even 10 milliseconds between the scans.

However, if you can set your scan time fixed at, say, 5 ms (and provided your logic can be executed in less than that time), your system becomes deterministic. You cannot avoid inherent latency and lag. But you can predict it and deal with it.

I am dealing with assembly, packaging and machine tool-type applications; we are using a dozen or so servos per machine so positioning is bread and butter for us. We use a different brand of PLCs, comparable to CLX by its capability. A typical servo runs at 3000 rpm (motor shaft, of course), has 10:1 gear ratio to the working end and fitted with 2048 ppr encoder, so we have 8192 counts per rev. We usually set fixed scan times anywhere between 2 and 5 ms. Like I said, this allows us to detect positions within 10 degrees window - and that is in most cases acceptable for the app.

If you have to do anything that has to scan faster than 2 ms (very high speed, very tight positioning accuracy), then a PLC is not for you. As Peter Nachtwey would say, that would be a job for a DSP-based controller - but this is an entirely different game...

There are some things to understand first about a CLX.

In the CLX your project is organized into one or more tasks. Under each task multiple program can be configured, and each program can have multiple subroutines. The Main task is a continuous task. All other tasks are scheduled. A scheduled task in one that you configure to run once every n milliseconds, for example, every 5 milliseoonds. Once each period this task will interrupt the continuous task and execute once from beginning to end. Tasks have priorities, with higher priority tasks able to interrupt lower priority tasks. Once the task completes, control returns to the continuous task. A task may also be an event task. You can configure the CLX to run that task whenever an IO point changes status or an analog input changes by a set value. This is configured in the IO card, and the IO card generates the evetn, so it doesn't require processor overhead to watch for the event. Event tasks run only when a change occurs. You might want to consider moving your resovler to an event task or a fast periodic task. Also in the CLX multiple processors may reside in the same rack and share the same inputs, though only one procesor can control a given output. A CLX in a different rack can even control io in the first rack, even if a CLX processor is in the rack. Certain applications might reqire you to have two processors in the rack, though I think that would be very rare. Read up on Event tasks in the CLX online manuals. It sounds to me like an event task is the best solution for your problem.

To see what a scan time is, while online, on your project tree, right click on you task. For example, click on Main Task. Select the monitor tab. The last scan and max scan times will be displayed there. But if its a periodic task that does not mean it is repeating that fast, the repeat rate is set by the tasks period.

I'm an old C programmer myself, so I really like the CLX processors. Everything I do now I do in a CLX unless a brick is all that is needed. I suggested to the AB product manager that they roll out a CLX brick (maybe based on the ML1200) I think it would sell.

One other thing, I have been told, though I haven't tested it, that when doing math intensive work that ST is considerably faster than ladder. You might try moving your 50 rungs of math to an ST routine. The beauty of the ST routine is that you can build a nice equation instead of storing all the intermediate resutls. For example:
If you want D = (A+B)*C

In ladder you have the following two rungs:
Add A B E <- add A and B and stor at E
MUL E C D <- now Multiple E and C and store at D

The processor spends alot of time moving the results back and forth from memory.

In ST you would program the following:
D := (A+B)*C;
The PLC doesn't spend time storing intermeidate results in an intermidiate tag, it solves the entire equation in the processor stack. With complex equations this can be a big advantage.

I hope that helps.

Darren,

What is the 1756 module supporting the resolver input? For very high speed applications the 1756-PLS is spec'ed to give 1 deg of detection at 1800rpm and supports 8 Inputs and 8 Outputs deterministically driven from the PLS module itself and independent of the main PLC scan. But from your post it doesn't seem that this is what you are using.

Therefore the next question is...how are you getting the resolver input in?

If my memory serves, I believe you're using one of the AMI resolver modules (from one of your previous posts). As I understand it, they make modules with and without integrated I/O. For anything but the slowest RPM or the coarsest resolution, you should be using the version with integrated I/O. It handles the output switching internally without influence from the CLX scan time. You configure the module with the switching angles and also speed compensation.

I have used the AB 1756-PLS but have only read about the AMI units.

Alaric pretty much said everything I was thinking.

There are a couple of tidbits I'd throw at you:

You can increase or decrease the "system overhead timeslice" to sacrifice communication and other maintenace tasks for scan time. But, you'd better check some tech notes for advice on how much to tweak it.

Also, I've noticed that large function block programs eat up memory like it's a free buffet. Try keeping your code in ST or Ladder if you want performance, and the ability to edit online without going for coffee breaks.

BTW: I'm at a public terminal, killing time. Sorry for not being logged in.

AK

Is this the same project?

This is driving me nuts!!!!!

my math is WAY rusty...

Scan time is 640 Micro seonds
Resolver is spinning at 50 RPM
50 RPM=0.84 Revs per second..

Resolver is set for 720Degrees...
So the resolver is turning once ever 800milli seconds (?? heres where i am getting confused) SO 1 degree on the resolver happens every 900 micro second's..(am i geting this right so far?) so it IS possible that i am missing a degree angle in a scan.. ..So i cant use EQU intsruction's..i will have to LMT and set a few degrees above what i want??..This dosnt make sence becouse the controller that ran this machine before was a PIC409..While advanced at the time they are a boat anchor for this day and age..shouldn't the CLX be able to scan faster that the old one??

BTW i tried playing with the time slice but it will only go to 10% nothing lower...

Click to expand...

Let me guess...you're using an AMCI 1241 resolver module and want to have PLS functionality.
Try this:

• create a virtual axis (rotary)
• use the velocity info from the resolver to jog the axis
• slave a MAOC output cam to the virtual axis
• use the position info from the resolver once at startup to synchronise the virtual axis position

You will get 32 PLS outputs that can be speed compensated.

"I feel my scan time is to low..my program relies on a resolver heavily!! and after i do the math the resolover is changing postion to quick for the scan time..Ie. turn output x on at 360degrees..however when the resoolver is reading 360 degress the PLC "Missed" it and i have to program 360-363 or so..."

What kind of resolution do you have in terms of inches-per-degree.

If your resolver is connected to the drive motor and the output of the drive motor goes through some reduction to the final device then maybe you have the resolver mounted in the wrong place.

What kind of resolution do you need? That is, in terms of the final device, what kind of accuracy do you really need? +/- 1-inch? +/- .001-inch?

How fast is the resolver rotating?

How many pulses per Rev?

In general, you should never look for "Degree = X". You should look for "Degree >= X" or "Degree <= X".

In most cases, you should be able to connect your resolver through a speed reducing linkage. The limit on the amount of reduction will be tied to the resolution you really need.

I see you guys are playing dentist again.

Oh well. I don't see the problem. Terry is right about not doing a compare with the trigger position only. I subtract the current position from the trigger position and then exclusive or that difference with the last difference and look for a sign change. The result of the XOR will be negative with a sign change. The only problem is this technique will trigger at the trigger position and the trigger position plus 180 degrees. This is not really much of a problem.

Gerry said:

Let me guess...you're using an AMCI 1241 resolver module and want to have PLS functionality.
Try this:

• create a virtual axis (rotary)
• use the velocity info from the resolver to jog the axis
• slave a MAOC output cam to the virtual axis
• use the position info from the resolver once at startup to synchronise the virtual axis position

You will get 32 PLS outputs that can be speed compensated.

Click to expand...

Sorry it took so long to get back on line..on the road again!!

Yep same project.. and yep its the amci resolver module..ONLY becouse my rep told me ab didnt make a resolver module for CL

As for your suggestions let me see if i can get this right..

Create a "Fake" axis and use the RPM from the resolver to turn the "Fake" axis..You lost me with MAOC??

[/QUOTE=terry woods]In general, you should never look for "Degree = X". You should look for "Degree >= X" or "Degree <= X".[/QUOTE]

This is how i overcame the problem i was just wondering if there was a better way..BTW my scan time is +- 640 Micro seconds..Is that about average for control logix or could it be higher?? I will play around with the program when i get home and try and only call my math routine on "machine start" or something along those lines..

Thanks for all the replies

darrenj said:

Yep same project.. and yep its the amci resolver module..ONLY becouse my rep told me ab didnt make a resolver module for CL

Click to expand...

Time to change reps, or at least educate him.
The module is 1756-PLS, takes 3 slots (2 are dedicated I/O), uses a specific AB resolver, is configured via ladder program, and, once configured, operates like a stand-alone sub system.
Does your rep also sell AMCI? Ask about their type 8213.

darrenj said:

As for your suggestions let me see if i can get this right..

Create a "Fake" axis and use the RPM from the resolver to turn the "Fake" axis..You lost me with MAOC??

Click to expand...

MAOC - Motion Axis Output Cam (an instruction)
The position sync won't be as simple as I indicated and probably should be checked periodically, since there would be a time lag between getting the resolver rpm and transferring it to the virtual axis. Would require a "registration" input.

Alaric said:

The beauty of the ST routine is that you can build a nice equation instead of storing all the intermediate resutls. For example:
If you want D = (A+B)*C

In ladder you have the following two rungs:
Add A B E <- add A and B and stor at E
MUL E C D <- now Multiple E and C and store at D

The processor spends alot of time moving the results back and forth from memory.

In ST you would program the following:
D := (A+B)*C;
The PLC doesn't spend time storing intermeidate results in an intermidiate tag, it solves the entire equation in the processor stack. With complex equations this can be a big advantage.

I hope that helps.

Click to expand...

Alaric

Have you ever tried to use the CPT instruction. There is no intermediate storage of values. Just select the destination and then write the expression.

"...BTW my scan time is +- 640 Micro seconds.."

What does this mean?

640 Micro seconds = .000640 seconds.

If your emphasis is on the +/- then...
Assuming a base scan time of 20 Milli-seconds...
+/- 640 Micro seconds would mean...

20 mSec - 640 Micro second = 0.019360 (min)
to
20 mSec + 640 Micro second = 0.020640 (max)

Or is it the case that you really meant 640 milliseconds (as in 0.640 seconds)?

If you really have a scan time of .000640 seconds... that is really, really fast!

If you really have a scan time of .640 seconds... that is really, really slow!

So... what is it?

MisInformed said:

Alaric

Have you ever tried to use the CPT instruction. There is no intermediate storage of values. Just select the destination and then write the expression.

Click to expand...

I do use the CPT instruction. And if you get creative you can embed quite a bit of code in there, including If Then statements and the lot, but 50 rungs of math is a bit much for one CPT instruction. I imagine it could handle it, but I wouldn't want to have to decipher that in the single line of ST the CPT instruciton give you.

On a side note, I have asked Rockwell to create a ladder instruction that can be used to embed a line of ST in ladder so that the FB instruction set can be used in ladder without having to create a seperate FB subroutine. I dont know if they will or not, but I think it would be useful. As it stands, the more CLX programming I do, the more ST I seem to use.