Missing signals or delay in reading them

Ignition
1

Hi,

we have a connection PLC <-> OPC <-> Ignition. We exchange about 700 tags. Some of them are requests signals, to send data further to MES. We encounter a problem, that sometimes Ignition doesn't receive the request signal (we know it, because when Ignition doesn't respond to PLC with 'done writing' signal in 5 seconds, the PLC set an alarm). The poll rate is 200 ms. Do you think, that this may cause the problem?

2

That is a relatively fast rate, but not necessarily impossible. More importantly:

  • Are you actually achieving the 200ms poll rate? (IA's drivers will show this in their diagnostics. Other OPC servers would have to show it in their UIs.)

  • Are your "trigger" signals maintained in the PLC until Ignition responds? If they aren't, and the OPC driver hiccups, you certainly can miss short signals.

3

  • We have to check it out. We are using Kepware.

  • Yes, it is maintained for 5 seconds.

4

That would be a "no", then. If you are using just time, then you aren't holding the trigger until Ignition responds. How do you know the "writing" part of your action doesn't occassionally take more than five seconds?

5

We don't check, if the "writing" part was performed correctly. We immediately respond to PLC with "done" signal.

6

Does the trigger stay on until that done signal is received? And the done signal should be turned off (by Ignition) when the trigger is reset.

7

Yes, the trigger stays ON until Ignition sets "Done" signal to 1. After that, PLC sets "Write" request and "Done" to zeros.

8

How many channels are you using in Kepware? I use Kepware for the Fanuc Focas protocol on some CNC machines. I originally had all of my devices under one channel, and I experienced heavy latency on several of the tags. I reconfigured it to use one device per channel and the lag disappeared. I haven't had any trouble since.

1 Like
9

We are using two channels. I would say that about 30% of tags are on the first channel and the rest on the second. How many tags you were using?

10

I have 6 devices with 23 tags per device at 100ms scan rate, considerably less than you have.
image

11

Might want to move the "Done" clearing to Ignition like pturmel said, it'll make it easier to avoid possible race conditions where the PLC keeps wanting to clear it and Ignition thinks it should still be on.

12

I don't understand the race condition here. Ignition sets "done" to 1, so then PLC sets "write" and "done" to 0.

13

Writing from different directions can confuse polling drivers. Don't do it, except perhaps in some startup/initialization operation.

14

Hi,

first for all, thx for all responses. I've checked the "done" signal and it turned out that only Ignition writes to this variable though, so sorry for the confusion. I've changed the poll rate to 1000 ms and it significantly improved the connection. So far we have not had any cases of communication suspension.

15

Hi,

I'm coming back to a similar topic as the one above.

We have 2 variables: WriteRequest and xOK.

Our task is to send the state of the xOK variable (0 or 1) to the database, when a WriteRequest signal appears.

Sometimes we send xOK = 0 to the database, even though xOK was '1', because WriteRequest was earlier.

The automation engineer, who programs the PLC sent me such screen, to show that it's not problem with the PLC:

image
image1413Ɨ715 60 KB

As you can see, xOK is set by PLC 90 ms earlier than WriteRequest. As I have no experience in programming PLC, I have some questions for you:

  1. Is this 90 ms time constant? Or is it possible that, for example, the PLC processor will be overloaded and will send xOK later by several hundred milliseconds, so it will be later than WriteRequest?

  2. Are the variables that go to the SCADA system through OPC Kepware queued in any way? We have set the cycle time in Ignition to 1000 ms and even though these variables are close to each other, in 99.9% of cases, xOK comes earlier than WriteRequest. But once in a while, it's the other way around, and isn't this related to my question number 1?

Thanks for your response.

16

See Nick's topic this morning that I just replied to:

Your simplest solution is to monitor the trigger tag with a tag change event then use system.opc.read*() to get the actual data. Subscribed tags cannot and do not guarantee order of delivery.

2 Likes
17

Thanks for response!

Does it mean I should also use system.opc.read() on xOK tag?

18

Yes.

1 Like
19

And what about the Siemens Ignition driver? Would there be the same problem as well?

20

All drivers. All OPC client connections.

1 Like