Speed tips


#1

Hi first time poster here, part of our application regards turning On/Off green/red lights with regards to a door being open or closed. Since we have lots of doors and lights distributed between multiple PLCs the time that lapses when the door is opened and the light turning red is in the range from 2-4 seconds which is too long. We would like it to be at 2 seconds at most.

In some instances the door switch is on one PLC and the light is on another… Can you give us some tips for the fastest communication betwen PLCs (how to properly communication between PLCs using scratchpad).

Also since we have lots of doors and lights, how can we read/write to points the fastest way possible? We think this is where the majority of our delay comes from, since we go through 4 fairly large while loops before writing to IO unit using MoveNumTableToIoUnit function.

We have considered writing to points directly, which does help considerably, but since we have a lot of point to look at (in “if” statements) it slows the chart down to a point where we would have no gain with reading/writing directly to points… Can you give some tips with regard to reading/writing to a multitude of points as fast as possible in a single chart?

If I have given to little information please let me know :slight_smile: thank you!


#2

Hi Blaz,

Welcome to the Opto 22 Forums.

I’m sure OptoMary will be along soon with some thoughts on this one, but my first thought (often wrong :wink: is this…

You mention a door switch and a red/green light. No timers, no logic, just a simple ‘if the door is open, green light, if the door is shut, red light’.
If that’s the case, then check out ‘Mirror mode’.
You can read about it in the OptoMMP Protocol Guide. http://www.opto22.com/site/documents/doc_drilldown.aspx?aid=1875
Check out page 125.
In a nut shell, it was built to mirror an I/O point from one rack to another… In other words, a digital input at one place, gets streamed over the network to a digital output at another place.
Its pretty fast too, like sub second fast since it uses UDP streaming.

So, your door switch is the input and the output is the light. If you use something like the SNAP-OMR6-C relay module which has normally closed (green light) and open contacts (red light), then there is nothing more to use or do.
However, for your existing switches and outputs, you will need some glue logic or hardware (since mirror or streaming mode is point to point and your output is two points). You can either wire a diode/relay on the output, so the light will toggle based on the input.
Or you can set up an event reaction.
Check out page 136 and on in the same MMP Protocol Guide.
An event reaction is something that you set up on the brain that is separate from the strategy.
Its blazing fast when its running, but a little tricky to set up the first time, but since your needs are modest, it would be worth a look.

So, two options, streaming or mirror mode and event reactions. Neither use a strategy, so are super fast.
They are what I would look at.
(Unless I am totally wrong and you have some logic in the middle that requires a strategy - in which case we have some thoughts on that too).


#3

Oh boy, well Ben’s right, I do have some thoughts on this. Certainly before jumping into the not-so-simple MMP features of event reactions and mirror mode, I’d want to have a better idea of where the real bottleneck is here. Especially since you’re talking about SECONDS not milliseconds here.

I’m also not clear on why/how the scratch pad is being used. When you say “door switch on one PLC and light switch on the other…” I’m guessing here you’re actually using something like an on-rack PACs like a SNAP-PAC-R1 or -R2? And they’re both running strategies? Since we’re talking about I/O points here (vs. other tags like an int32 or float) I’m not sure why you’d use the scratch pad, vs. having on PAC-R with and I/O unit configured in its strategy for the points on the other PAC-R.

Can you give me a little more of the “big picture” here, or a series of steps of what happens between when a sample door opens here and a sample light goes on over there? That might help better sort out where the delay is and how to (most simply) shorten that delay.


#4

hi to the both of you :smiley: first of all thank you for the fast responses :slight_smile:

@ben orchard: . I did not explain properly what we are doing, so I will explain a little further :)… when a door opens the lights on the opposite doors need to turn red (so people know not to enter the room at that time), problem is we sometimes have multiple doors and lights in the same room (2 < n_doors < 6), so when one door opens, the lights on all the opposite doors need to turn red, in other instances when 6 < n-doors, then we allow x number of doors to be open at the same time, but if the number of opened doors is higher than X then all of the lights on the doors need to turn red … I think that “Mirror mode”, by the way it sound, is not going to work, but will have a look at event reactions :slight_smile:

@mstjohn: you are correct we are using SNAP_PAC_R1 and SNAP_PAC_EB1 connected to the R1. So the R1 and EB1 are connected as follows: mutliple R1 are on the same network and can communicate with each other, however each R1 has a local network to which the EB1 are connected, I think we cannot reach the point on the EB1 on a R1 that is not in the local network (unless I’m wrong :slight_smile: ) next I will try to best describe the big picture:

so currently it goes like this: a door opens, we read the point values with the function “MoveIoUnitToNumTable” to a table which then goes through two while loops which we use for inverting the values and manually controlling points… we the store information about open doors bitwise in integers which we then send to a central R1 which gathers info from all R1, this one read all scratchpads and writes to its own in a seperate chart which runs about 0,8 seconds, other R1 then retreive the gathered information from the central R1 via scratchpad to a temporary table which then goes through two while loops for again manually controlling points and inverting values and then write to points using “MoveNumTableToIoUnit” … the loops can be bypassed for doors and lights since this is where the bottleneck is but like I explaind in response to ben there is a little bit of logic here and if we write to a point (light) directly when we read a door (a bit through scratchpad) is opened, it goes faster, but since we have a lot of doors and lights than the chart will slow down, currently I’m leaning toward using the scratchpad to distribute information and event reactions to view and manipulate points for doors an lights, I’m guessing that an event reaction is faster then reading/writing points by their name in a strategy?


#5

is it possible to configure Event/Reactions within PAC Control Pro in a text way? or is it only available via PAC Manager by clicking?


#6

Yes, you can configure Event/Reactions (or pretty much anything else you see in PAC Manager with a mem map address) using commands in PAC Control. See the group: “I/O Unit - Memory Map” for commands like Write Number to I/O Unit Memory Map.


#7

I’m having a hard time guessing why the strategy described is taking hundreds of milli-seconds or seconds to run. Nothing mentioned sounds very CPU intensive, and the TCP/IP communication between devices will be very fast. Bitwise operations should be efficient, especially if a mask is used to due the inversion.

Do each of the loops have a delay built into them? Maybe the OP can share the strategy. While Events and scratchpad communication might go faster, there may be a way to speed this up without adding that complexity.

As the OP suggested, I have also found that using “MoveNumTableToIoUnit” gives a more predictable response time than lots of discrete read/writes. With some chart optimization, the strategy sounds like it should execute <100 ms.


#8

I agree with sensij for here we have 7 controllers connected throughout our plant with close to 1000 I/O’s using every type of comms. including the scratchpad. My first thought is maybe the cost of replacing the EB1 with an R1, change it to e-net and then you can use one of the other R1’s as a controller and have direct access to all I/O’s. Then make a chart to just move all I/O units to assigned tables and variables and work off of that. I too have been constantly working with keeping the charts and strategy times down but even those that are more complex with 12 charts running are faster then 100ms like sensij mentioned. In fact what really can slow down controller speeds the most here is the Runtime, and how it is configured…