intentionally slowing scan time

If i said i cant fill you in as to why it needs to be done this way dont you think there is a REASON.
Slowing the scan time is a particularly poor way to work around a problem that you perceive as being related to scan time.
Most PLCs are set up to have a watchdog timer associated with the I/O service. If the physical I/O points are not serviced within the watchdog timer preset value, the PLC gets shut down and all of the outputs are commanded to their default states, generally OFF. That's because if the PLC is not communicating with the I/O points, the machine is not under control.
That's why the questions were raised by your statement that you weren't allowed to solve your problem any other way.
 
Slowing the scan time is a particularly poor way to work around a problem that you perceive as being related to scan time.
Most PLCs are set up to have a watchdog timer associated with the I/O service. If the physical I/O points are not serviced within the watchdog timer preset value, the PLC gets shut down and all of the outputs are commanded to their default states, generally OFF. That's because if the PLC is not communicating with the I/O points, the machine is not under control.
That's why the questions were raised by your statement that you weren't allowed to solve your problem any other way.


For sure, i totally understand that Steve.
Your support and suggestions are always appreciated.
 
If it's a bit monitor it and use a One-Shot to set a bit to watch

If you want to monitor a value change then compare the variable to Last_Scan_Value_Of_Variable and if not the same then have a bit come on. Then on the next rung, after the compare, move the variable to Last_Scan_Value_Of_Variable
 
Wait guys.
rscott9399, are you latching I/O?
Is the I/O changing rapidly?
If the I/O update is asynchronous to the PLC scan there can be read-modify-write problems.

I do agree that lengthening the scan is not the real solution but there may be others.
It would have helped to show a screen capture of the ladder.
 
Wait guys.
rscott9399, are you latching I/O?
Is the I/O changing rapidly?
If the I/O update is asynchronous to the PLC scan there can be read-modify-write problems.

I do agree that lengthening the scan is not the real solution but there may be others.
It would have helped to show a screen capture of the ladder.

Totally agree Peter normally i would do that.
Cant this time.

Thanks for your input. Ill figure something out.
 
Even if your example was valid, slowing the scan time would do absolutely nothing to fix your LOGIC problem. Slow it down to 30 minutes per rung execution, and it still executes (and fails to work the way you want) in exactly the same fashion, it just takes longer to fail.
Fix you logic first.
 
Thanks anyway, forget i asked.

Always easy to point fingers instead of offering suggestions.

If i said i cant fill you in as to why it needs to be done this way dont you think there is a REASON. Perhaps im bound by law to not discuss it?
Instead of just giving me a hard time how about just not comment?
Not pointing the finger at YOU, at the situation s you described, which is patently ridiculous as other have pointed out. Even if scan time "fix" the issue, it will be unreliable and unpredictable.

I have walked off unsafe job and unsafe situation and I tell all young engineers to do that same. I don't walk off engineering challenge. What you described is not an engineering challenge.
 
You have to look at things from our perspective, we can't see things from your eye that's why I said something is missing from the translation. I'm one of the biggest offender of that, as English is not my first language. We are not telling you off, only that it sounds absurd.

It sounds like you are not allowed to change the logic, that's what we are reading here.

But can you ADD to the logic?

If so, you can easily capture the 2 events, one latches, the 2nd event unlatches into separate status bits then use the sum of those to trigger the events. then scan time won't be an issue.
 
Are you allowed to modify the program at all?

what you are describing is a line scan program approach / grafcet approach.

for example
rung 23 - latch bit b3/1

rung 24 b13/1 is required to be on in order to latch b3/2
which is not on, so the remainder of the program is skipped and you start back at rung 1.

rung 20 - copy file b3 to file b13.
rung 23 may still be true
rung 24 - b13/1 is now true and when the logic is complete, latch b3/2
AND unlatch b3/1
rung 25 now requires bit b13/2 to be on.
scan the entire program and go to rung 1.
rung 20 now copies b3 file into b13.

see the pattern.

this type of programming will work, BUT, you must program the alarms and faults accordingly.
you must also reset the files after a fault, depending on what you are doing.
it can get messy and I frown on it.

this way, you execute 1 rung of code per scan.

hope this helps.
james
 
Last edited:
Thanks anyway, forget i asked.

Always easy to point fingers instead of offering suggestions.

If i said i cant fill you in as to why it needs to be done this way dont you think there is a REASON. Perhaps im bound by law to not discuss it?
Instead of just giving me a hard time how about just not comment?

We have run into this issue many times, once the logic has been tested and certified by big brother, no one is legally allowed to modify the logic without a recertification test, which is extremely costly. You are stuck dealing with bugs and poor logic until an update or it becomes cost effective to make changes.
 
No idea what rscott9399 is working on but I have heard of some pretty complicated rules about program changes when it comes to sites like power plants, water treatment etc. If the site was approved with a particular program running, it's an entire round of complicated change notices to change one bit in the program. My guess is he's dealing with something like that.

But then, is slowing the scan time safe either? Guessing rscott9399 knows what he's doing.

Slowing it a little might be a troubleshooting technique to help see what is going on. Like Ron Beaufort always cautions, what you see on the screen isn't necessarily what is going on in the PLC. There is a layer of communications and graphics drawing that happens before your eyes get a look. In that time, the PLC could have gone through its scan multiple times.
 
I think we are already past this, but there is a disquisition to slowing down cycle.


Increase the time between two consecutive scans, or
Decrease the number of operations per second, ie decrease the clock speed.


As mentioned, this is a bad idea, and probably won't help you. The sequence of things will be the same. Your program is being run sequentially.


People here are more than willing to help, sometimes comments may seem ****y, but remember we are engineers. Most of us don't have social skills :)
 
If we could see the logic, we could suggest how to fix the problem.


It might be that a simple change in rung evaluation order would solve it, by keeping the latched bit on for a whole scan before it gets unlatched.



All PLC manufacturers invest huge amounts of time and money into making their PLCs scan the fastest, and attempting to slow one down to fix a simple logic problem (which it won't fix anyway), is just a no-no IMHO.
 
I had something of this kind of situation, where I had a continuous task that needed to send a one-shot bit signal to a periodic task. Sometimes the periodic task got the signal, sometimes the continuous managed a second scan before the periodic had one, and so the one-shot got reset and the periodic task never saw the command.

The solution was NOT to slow down the scan of the continuous task.

These two tasks running asynchronously is no different than I/O, HMIs, and other PLCs communicating asynchronously. Either handshaking needs to be introduced (what I refer to as "Mother, may I?" "Yes, you may"), or have the Commander (source PLC or HMI) set the command, and the Receiver reset it.

The fact that you are having the Commander doing the setting and the resetting is the flaw in your code, not how often they pass messages to each other.

I often work in regulated industries, and know that some changes cannot be made. Without Authorization. Get the authorization to make the correct change. Slowing down the scan is just going to have unintended consequences elsewhere. Probably with I/O not responding in a "timely" manner to conditions, and affecting product quality.

As others have been saying: Do this the right way. Slowing the scan time is NOT the right way. Ever.
 
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.
 

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,942
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,684
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