Is Cop instruction need time to be executed ?

[MedSelmi]

Hi experts,

I'm troubleshooting a program with rslogix5000. there is many cop instruction of array, but sometimes some data are not copied.
As you see in attachment, every cop instruction had 50ms to be executed.
I'm wondering why programmer use timer to execute copying data?
How can I assume the necessary time? for example why not 40ms?

BR

 

[id10t_error]

Without seeing the entire program and datatype being copied, who knows, but I believe the timing has to do with the physical belt's position and time than with the copy instruction.

 

[James Mcquade]

assuming that m58.14 is true, you have two conditional copy statements happening. if the timer is between 0 and 50 ms, copy Tracking_Closer_Belts[1]
into Tracking_Closer_Belts[2] EVERY scan. when the timer is >50, this copy statement is ignored.
then when the timer is between 51 and 100 ms, you copy Tracking_Closer_Belts[0] into Tracking_Closer_Belts[1] again every scan. when the timer is between 0 and 50, this copy statement is ignored.

the lim instruction is nothing more than two math statements. if the timer value is >= 0 and <=50, do the copy statement, otherwise do not execute. the same can be said for the other copy statement.

as to why some data is not being copied, we would need to see your entire program. it could be that a routine is being called that skips over this logic, this routine may not be called at times, the routine may not e needed at times.
why did the programmer use 50 ms windows, you would have to ask him, everyone does things differently.
hope this helps,
james

 

[drbitboy]

Is Cop instruction need time to be executed ?
[...]

As you see in attachment, every cop instruction had 50ms to be executed.

Unless I am misinterpreting the question, that is not what I see. What I see is that the first of these COP instruction is executed on every scan that executes this rung during the first 50ms when M58.14 is 1, and the second COP instruction executed on every scan that executes this rung after that as long as M58.14 is 1.

The execution time of the COP instruction for 1 DINT is less than 1μs, and even considering the extra for indirect addressing, the execution time of the instruction is unlikely to be an issue.

That is very different from "every COP instruction had 50ms to be executed," although perhaps OP meant to say "every COP instruction had 50ms over which it may be executed multiple times."

A scan time longer than than 50ms is unlikely, so it is unlikely that these COP instructions do not occur when conditions allow; even for a scan time greater than 100ms, any scan on which M58.14 is detected as a 1, when it was 0 on the previous scan, will always trigger the first COP (.ACC will be 0).

 

[Aardwizz]

A scan time longer than than 50ms is unlikely

That depends on the size of the program, Continuous or timed task (its frequency and its priority over other tasks which may interrupt it), the processor and how much HMI traffic is interrupting the system time slice. Because of these things, I can see where "sometimes it works and sometimes it doesn't" might happen.

When M58.14 is true, the timer will start, the ACC will be 0, and the first COP will fire, as you said.

If the scan takes longer than 100 msec, the ACC will be > 100, the .DN will get set, but the second COP won't execute. The .DN bit will then fire the End of Tramsfer <sic> coil.

 

[drbitboy]

If the scan takes longer than 100 msec, the ACC will be > 100, ...

whoops, actually, .ACC will be equal to 100 (i.e. the .PREset) and the second COP will fire, assuming M58.14 is still 1.

But I take your main point, that there are a lot of caveats and reasons why these COP instructions might not execute.

IIRC, 100ms was the nominal minimum scan time specification for early PLCs; the rationale was that a typical relay would take of order 100ms to close. That might not mean anything today, but that number does show up from time to time e.g. the default watchdog timeout of the continuous task on MicroLogix 1100 is 100ms (10 10ms periods, S:3).

 

[MedSelmi]

Thank you all for your responses,
I get more details about the problem. So, there are parts of molds (drag and cope) moved by belts and monitored by scada. every drag or cope have its own data using UDT(see attachment).
So, when belts move and there is a transfer, data will be copied from previous position to next position then empty the first position by copying ''Tracking_Closer_Belts[0]''.
the problem sometimes I get 2 similar parts ( drag and drag ), that's means drag data copied from Tracking_Closer_Belts[1] to Tracking_Closer_Belts[2] but Tracking_Closer_Belts[1] still have old data of drag. it seems like copy from Tracking_Closer_Belts[0] to Tracking_Closer_Belts[1] not executed.
some hints please ?

 

[Mispeld]

Are you sure the [0] element (in the first example) is set/updated before the copy instructions execute?

 

[MedSelmi]

Are you sure the [0] element (in the first example) is set/updated before the copy instructions execute?

the [0] element has the same data structure with all values zero, it is used to empty position and result no display of mold in this position(on scada).

 

[drbitboy]

This should work as long as the latch of [Transfer Code Closer>Platform M59.7] does not happen on the next scan.

 

[drbitboy]

If the 100ms is needed to prevent M59.7 from being re-Latched elsewhere, then this could be done to prevent that happening for 100ms:

 

[drbitboy]

Or this, with no changes to the other location's Latch of M59.7, ensures these COPs happen exactly once on the rising edge of M59.7, and cannot happen again until at least [100ms + one scan time] after the other location stops latching a 1 into M59.7.