News:

  • October 04, 2026, 11:31:16 AM

Login with username, password and session length

Author Topic: Program.Running glitch? Please help me troubleshoot  (Read 7985 times)

Bolt

  • Hero Member
  • *****
  • Posts: 598
Program.Running glitch? Please help me troubleshoot
« on: October 14, 2018, 10:42:52 PM »
I have a BRX, and have had a similar rung in there for months.  After some simple program changes, it no longer acts like it did before.

I have dumbed it down to the simplest version and it still does it to me. 

It does not matter which Program.Running I put in the leading edge one shot, any (continuously) running program energizes the output, C959 in this case.  I can reset C959 in a DataView, it turns back on almost instantly.

What am I overlooking? 


franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3847
    • Host Engineering
Re: Program.Running glitch? Please help me troubleshoot
« Reply #1 on: October 15, 2018, 08:38:06 AM »
Your expectations are correct, C959 should NOT be turned ON after being cleared from a Data View - I verified this behavior with a cleared PLC and the logic you have.

I presume that your program is not EXITing or being HALTed, then re-RUN, but that could be a (very slim) possibility.

The only thing I can think of is that your C959 is being set somewhere else?  Float your cursor over C959 to bring up the XRef tooltip and see where else it may be used as an OUTPUT.  You might try using the Find dialog (Ctrl+F) with the settings I have highlighted in the attached screenshot.  It does a good job of finding elements in ranges, in casts, etc..

Another possibility, if you use indirect addressing, e.g. C[V100] somewhere as an output parameter, then maybe it is writing?  Indirect addressing cannot be statically found/xref'ed since it is dynamic at runtime, so this just requires a good debug session, maybe with some additional debug logic.

Ranged instructions can also be an issue, e.g. SETR or RSTR or MOVER or whateverR (Find should catch these).

Lastly, maybe another device (PLC, HMI, ???) is writing to C959 remotely?

Bolt

  • Hero Member
  • *****
  • Posts: 598
Re: Program.Running glitch? Please help me troubleshoot
« Reply #2 on: October 15, 2018, 10:01:55 AM »
I presume that your program is not EXITing or being HALTed, then re-RUN, but that could be a (very slim) possibility.
Correct.  No HALT's and EXIT only occurs about 2 times a day.  Program.RunCounter = 0 (after resetting last night)

The only thing I can think of is that your C959 is being set somewhere else?  Float your cursor over C959 to bring up the XRef tooltip and see where else it may be used as an OUTPUT.  You might try using the Find dialog (Ctrl+F) with the settings I have highlighted in the attached screenshot.  It does a good job of finding elements in ranges, in casts, etc..

My first thoughts.  C959 is just an unused coil from the address picker in a test rung.  The real problem appeared in a SGSET instruction originally.

Another possibility, if you use indirect addressing, e.g. C[V100] somewhere as an output parameter, then maybe it is writing?  Indirect addressing cannot be statically found/xref'ed since it is dynamic at runtime, so this just requires a good debug session, maybe with some additional debug logic.

Ranged instructions can also be an issue, e.g. SETR or RSTR or MOVER or whateverR (Find should catch these).

No indirect addressing used  in this range of memory.  No range sets, etc.

Lastly, maybe another device (PLC, HMI, ???) is writing to C959 remotely?

All external communication is through Modbus, so no write logic found in program.

Here's another iteration of the problem, relayed through a PD.

I have not been able to reboot the PLC, this occurred after a Run Time Edit.  I would kinda like to find the problem before rebooting.  I have may other one shot Program.Running contacts, and they seem to be working fine, at least not causing undesired responses.  I have also not gone back and re-wrote old version of program to the PLC yet.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3847
    • Host Engineering
Re: Program.Running glitch? Please help me troubleshoot
« Reply #3 on: October 15, 2018, 10:23:56 AM »
The INC helped verify the issue on the contact side.  I use INC a TON for helping debug power-flow behaviors (excellent debug tool).

If possible, email your project to support "at" hosteng.com and maybe we can duplicate it.  Please email the simplest version that can duplicate the problem.  Also, if you can capture all the retentive data using the Memory Image Manager (it saves it as part of the project), that may also help us duplicate it.  Before doing that, make sure you do a SAVE-AS so you won't be tweaking your ACTUAL project .dmd file, just this "copy" you will be emailing us.

1. Read project from PLC
2. Do File->Save-As to a new .DMD project file
3. Do Tools->Memory Image Manager and hit Generate New Image button at the top.  When prompted, select Create New Memory Regions with Current PLC Data
4. Hit OK in the MIM dialog
5. File->Save (this will save the MIM data to the new .dmd project file from step #2)
6. email the file to us

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6176
  • Yes Pinky, Do-more will control the world!
Re: Program.Running glitch? Please help me troubleshoot
« Reply #4 on: October 15, 2018, 12:09:37 PM »
No C-more, right?
"It has recently come to our attention that users spend 95% of their time using 5% of the available features. That might be relevant." -BobO

Bolt

  • Hero Member
  • *****
  • Posts: 598
Re: Program.Running glitch? Please help me troubleshoot
« Reply #5 on: October 16, 2018, 10:37:14 AM »
Correct, no C-more.  Only "HMI" is web based.  Sending email to support.