Heartbeat script having effects system wide

Ignition
1

I have four PLCs receiving heartbeats from the Ignition Gateway. They are four Gateway scripts running every second that:

  • Count from 1 to 60 and reset to zero.
  • Copy that value to an OPC tag.

I have tried a single script, four scripts, changed threading and delay…

The problem is if I unplug the network cable on one PLC, the HBs stop updating for all PLCs until they reconnect. Same thing when I plug back in. I can still ping the devices while the heartbeats stop updating.

** PLCs are four Allen Bradley CompactLogix.

Any help would be appreciated, thanks.

1 Like
2

I’ve had the same problem for several months now. I updated from 7.9.10 to 7.9.16 to see if that helps, and it didn’t. I have to reboot Ignition to get it working again, helps for abut 2 weeks. Memory and CPU usage is low. Doesn’t matter if it is a tag change, tag event or gateway timer script…they all stop running.

3

Have the HeartBeat generated by the PLC and monitored by Ignition.

@pturmel

4

Have the HeartBeat generated by the PLC and monitored by Ignition.

Isn't the idea here for the PLC to be able to detect loss of connection to Ignition, rather than the other way around?

5

Written correctly it will do that too. HandShake as well as HeartBeat.

And the OP said he can still ping. For my largest project with over 100 device instances, I run a periodic ping and record the results to DB, then report a summary every day.

6

How can you detect loss of connection to Ignition using a heartbeat generated inside the PLC?

7

e.g. PLC counts to a certain value, once certain value is reached, Ignition resets back to 0.

If not reset within a certain time == comms loss.

8

Hadn’t thought of doing it that way! Unfortunately I rarely have control of my end devices so I probably won’t get too much opportunity to use it :frowning:

let’s wait to hear from @jdrichards70 to see how they’re trying to achieve this.

9

Something to add to the Spec’ for your OEM then :wink:

10

Eeek! No. Don't write from two directions. PLC should count and roll over. The low word of a PLC clock is fine. Ignition should count and roll over in its own timer event, writing to the appropriate OPC tag. Or write the low bits of Ignition's millisecond time to the OPC tag. It isn't important what the value is, just that it changes regularly.

Neither the OP nor @jdrichards70 shared their actual scripts, so there's no telling what the real problem is. Non-blocking writes should be used to prevent one broken device connection from killing the heartbeats to other device connections.

1 Like
11

That’s why I tagged you I knew you would have me sat-corrected :slight_smile:

My Field IO is generally Moxa IoLogik. I use an E1212 with a hardwired heartbeat Output back to an Input on the same module, with the Output set to pulse at 1000mS.

SCADA monitors/trends/alarms this and combined with my periodic ping mentioned above, I have a good idea of RIO/FIO outages. I know when SCADA is down because my mobile (cell) phone rings shortly after :stuck_out_tongue:

1 Like
12

I think it’s more than just my heartbeat issue. Once in a while, the operators will report the barcode scans are taking 30-60 seconds to show up on the HMI or a machine will pause for a bit waiting for something from Ignition. Everything on the network pings < 1ms while this happens.

script is stupid simple:

x = system.date.getSecond(system.date.now())

system.tag.write(“Corporate/Lincoln/Bay A/Line 4/Proof/Carousel 1/Heartbeat Count”, x)
system.tag.write(“Corporate/Lincoln/Bay A/Weld/Welder 2020/Welder/Heatbeat Tag”, x)

and I’ve even done this just to see what happens:
(runs every 2 seconds)
x = system.tag.read(“Corporate/Lincoln/Bay A/Weld/Welder 2020/Welder/Heatbeat Tag”).value
x = x + 1
if x > 59:
x = 0
else:
pass

system.tag.write(“Corporate/Lincoln/Bay A/Weld/Welder 2020/Welder/Heatbeat Tag”, x)

The OEM will change the code for me if a better way is out there, this is what the programmer wanted, he’s just looking for a change in the value every 10 seconds.

Thanks for the help.

13

Please use the Preformatted Text option (</> button) when posting scripts and error messages, as that will preserve formatting.

Sounds like you are running code in the foreground (GUI thread). Anything long-running should be in a separate thread (Invoked Async).

14

Hopefully @jdrichards70 can confirm that the scripting in question is configured as a Gateway script; agreed that you'd not want this in the client scope. Perhaps confirm your settings for the timer script?

Screen Shot 2021-01-10 at 4.02.41 PM
Screen Shot 2021-01-10 at 4.02.41 PM754×531 152 KB

15

@Matrix_Engineering - yes, thank you, I forgot the formatting, doh!. I can try async.

@Kevin.Collins - I tried fixed delay and fixed rate, same results. I am running with dedicated thread right now.

What would the proper or industry standard be for setting up the heartbeat? I usually just use the ‘is connected’ bit with the driver and this is the only machine I have had issues with…Siemens, arg!!! While my heartbeat dies, all the other real time data is coming through, so it’s not like the machine dropped offline or the driver locked up and I can manually change the tag value in a designer.

16

Hello, I had the same problem today.
I have 2 OPC server and when I disconnect one, I see the timer script slow down and not writing the heartbeat to the second one.
(They live in two completely separate timer script)

I receive an error ( I can’t share it at the moment ) in the system log saying that there was an error on the timer script code, even if there is no error.
The whole timer script is just a write on the tag.

I tested system.tag.write and system.tag.writeBlocking with the same outcome.

Coul I ask you which settings are the best for a simple and reliable heartbeat?

I don’t understand why this is happening even if I select dedicated thread.

I remember fixed delay and fixed rate was bugged, is it still the case?

Thanks

17

There was a bug in the OPC tag execution system that caused breakage on a single connection to hold up all tags on the same pace across all other OPC connections. I don’t recall what version it was fixed, but your case sounds suspiciously similar. What Ignition version are you using?

18

I will post the gateway and errors details on Monday as soon I will have a remote connection with the server.
The version is the 8.x.x.
One thing I’d like to understand is how scripts are managed.
For example, let’s assume we have this scenario:

2 plc tags with one script each, when the value change (udt tags with event change script):

  • A writeblock writing 2 booleans to PLC, resetting the request bit and setting an ack
  • an opc.read to retrieve the state of few tags
  • store some values on a database
  • writeblock to write an integer plus a bool to the plc with the result of the action performed

2 timer script, setting a boolean on the plc as heartbeat.

Now my question is, if for example we are in the situation when the timer script and the tag change event fire at the same time, will they be executed on their own thread or they will share the thread and so be executed one after another (with obvious writeblock time delay) ?

The same question bother me for consequential events being fired at the same time on multiple tag change scripts.
There is a difference between how ignition treat gateway tag change scripts vs udt tag change? Are they executed on the same thread?
In case a writeblock goes in timeout due to connection probelm, block all the other script of changing tags?

Would be nice if you can point me out some documentation about it,
Thankyou

19

That is not how you answer "What Ignition version are you using?" The rest of the digits matter.

1 Like
20

Haha, a bit like “what’s your address?” “I’m in Australia”