intentionally slowing scan time

One thing you could try is to increase the System Overhead Time Slice. This is accessed on the Controller Properties, Advanced tab. In the version I'm looking at (V28) there is a selection below that with the choice of what to do "During unused System Overhead time Slice," either (1) Run Continuous Task or (2) Reserve for System Tasks...

It would seem that increasing the time slice percent and selecting Reserve for System Tasks will starve the Continuous task of execution time.

I was thinking of this as well, but I don't believe that it would actually slow down the scan time unless you had a lot of communications happening. I may very well be wrong, but I believe you're simply denoting how much of the system's resources are PRIORITIZING scan time vs communication, so if there isn't a lot of communications going on it will still perform normally in the scan time department.
 
I have had numerous problems with latches

Its kind of hard to explain

But to fill in the gaps ill give it a shot

Say you have several rungs that simply unlatch and latch the same bit.

So rung 1 latches it

Rung 2 unlatches it

rung 3 latches it etc

No pretend the bit that is being latched and unlatches is the trigger for some other operation

The issue i have found is that the scan time is so fast that the trigger never actually occurs because it cant unlatch itself quick enough before the next rung is latching it again.

So the trigger never changes state essentially

So if you could slow down the scan time you could actually get the trigger to move.

No i dont like this method or style of triggering things but unfortunately sometimes ijust have to do what im told and make something work which im sure you all have seen before.


Ugh ugly programming. Why have multiple destructive references?

In this example you mention - i think your problem is more related to the way this is programmed and not scan time. Are you latching and unlatching bits based on field devices? If so CLX is an asynchronous IO update - inputs can change during a program scan - this can bugger things up if not dealt with in a decent way.

In your example above,

because it cant unlatch itself quick enough before the next rung is latching it again

Step through the rungs one by one - if rung 2 resets a bit it is 0 after that rung has been scanned, if the next rung turns it back on again what do you expect? You would need to jump to some other section of programming to have effect in between the two rungs??
 
Just putting this out there...

JMP and LBL will loop you about the ladder logic during your scan. Had once where I wanted to repeat one rung 50 times to update some indirect address pointers without making a new structured text routine. Repeat your JMP instruction 100000 times at the end of every rung and your scan time will probably get a tad bit longer...
 
Latching and unlatching should be instantaneous. Think of what would be happening in assembly language. The only problem I see with latching and unlatching bits is that it is a read-modify write type of operation. The whole byte or word must be read into the CPU. Then the appropriate bit must be set or cleared and then the word or byte must be stored back into memory. This can happen in 3 instructions but to avoid any outside task or interrupt from fouling up the works, the interrupts should be turned off before the read-modify-write occurs and the interrupt state restored afterwards. This is basic stuff for embedded programmers. I doubt Rockwell would make this error and only rscott9399 find it.

I still think there are race conditions. Slowing down the PLC will not help.
 
Sorry about joining in late to the party, but if you are still looking for a way:

-> Go to your project settings by hitting alt+enter on the topmost folder in your tree, your controller properties should pop up.
-> Go over to System Overhead Time Slice: This setting changes the percentage of CPU time allotted to your foreground(Ladder) task take vs background(WebGUI/OPC communication) take.
-> Change it to a higher number. For example, if it is set to 80% at the moment, if you switch it to 60%, your scan goes 25% slower, Given that you are also toggling the "Reserve for system tasks" signal box.

-> A little bit of math: Let S represent scan time, and P represent the SOTS.
Therefore,
(Sdesired/Scurrent)=(Pcurrent/Pfinal).

Using the above equation, you can slow down the scan time to whatever you want. JUst get the Pfinal value and plug that into the SOTS.

Hope this helps!

-PeeLC
 
slowing down your processing from one rung to the next is a sure way not to solve your problem.

I agree. Slowing scan time won't fix bad logic. Latch functions are useful, and I'm not one to say that latches should never be employed, but many people are opposed to the use of latches simply because there are so many ways for a programmer to screw them up. Improper sequencing of latch and unlatch operations is certainly one of those ways.

If IO update asynchrony is the real problem here, then that could be alleviated by moving Inputs to holding registers and monitoring those holding register bits in the program, rather than the actual Inputs.
 
Last edited:
Let us go back to the OPs post and do a bit of analysis.....


Say you have several rungs that simply unlatch and latch the same bit.


So rung 1 latches it

Rung 2 unlatches it

rung 3 latches it etc

Now pretend the bit that is being latched and unlatched is the trigger for some other operation


Presumably there are conditional instructions on all these "latch/unlatch" pairs of rungs, and if they are both evaluated as "true", then the bit will be immediately unlatched after it was latched in the previous rung.


So if you want the bit to trigger "another operation", then it needs to be ON, so that it can be seen by that operation. Latching it ON in rung 1, and OFF in rung 2 means that it is only ON during the small amount of scan time between rungs 1 and 2, and OFF for the rest of the scan.


IF, and it's a big if, that is the case, then simply reversing the rung order ought to do the trick, so the bit will be ON for a whole scan before it is unlatched again in (the now) rung 1.


It sounds as though your code is not well-written, and without seeing it, we cannot advise better, but IMHO there are not many cases where you can't dispense with Latch/Unlatch pairs completely.



The issue i have found is that the scan time is so fast that the trigger never actually occurs because it cant unlatch itself quick enough before the next rung is latching it again.


That's a nonsense, the bit will NOT unlatch iteslf, It will only unlatch if the logic on the rung determines it should unlatch, and no amount of slowing things down will change that fact.



So the trigger never changes state essentially


Yes, it does, it changes state when the rungs are executed to change its state, no other time....



So if you could slow down the scan time you could actually get the trigger to move.


Not a chance, the "trigger" is being set and reset BY CODE, if the trigger is not ON when you want it to be, then your code is at fault, not the scan speed.
 
I hate to revisit this thread again but I really think this entire thread is an exercise in mis-communication or badly assumed premises somewhere along this game of "telephone"

Recall the OP also said this:"

Like i said its just an example to give a scenario that would require slower scan time

Why dont i do it a different way? as i said the answer is simple. Im not allowed to

I would also suggest looking at OP's other threads.
 

Similar Topics

Hello all, I was wondering if there is a way to turn on the SF LED using an instruction in the program. i.e. My PLC has no HMI and it has modbus...
Replies
12
Views
2,943
Hi, this is a problem that has been dogging me for months and I thought I'd ask here. I have a Direct Logic 05 PLC that I am using to interface...
Replies
9
Views
3,085
I have a powerflex 753 22 amp drive running a 15 hp motor, powering a short conveyor. At a commanded speed of 60 hz the conveyor is running 1200...
Replies
2
Views
1,291
Hello everyone, I have a question in my mind. I am working on bag-filling process. Now i have a motor that brings goods and a loadcell. My...
Replies
36
Views
20,686
Usually we want to do the opposite, but I'm actually looking for opposite, I need to slowdown my Siemens S7-1518 OB1 execution time, to say, 20...
Replies
6
Views
1,811
Back
Top Bottom