News:

  • August 14, 2026, 07:20:12 PM

Login with username, password and session length

Author Topic: Timer Pandamonium!  (Read 13375 times)

RBPLC

  • Hero Member
  • *****
  • Posts: 586
Timer Pandamonium!
« on: March 15, 2023, 07:55:27 AM »
See attached for reference. I haven't seen this before. Every timer in this Program, when monitored in ladder view, appears to be going crazy. The displayed done bit toggles ON/OFF, the .ACC values are huge and .Done, .Reset, .Zero, .Timing are all displaying at the same time. Every timer in the Program is displaying in this manner. The displayed info in the ladder view for every timer appears to be referencing the same reference registers as they all toggle at the same time and the .ACC values are the same. The only thing displaying properly is the Preset value for each timer. As shown in the data view, I believe the timers are running correctly, it's just the display of the info in the ladder view that is wild.

Edit:
See TP2 image. For clarification, when displayed in data view at high level all timers show "wild" values. When viewed at the individual element levels, everything appears to be correct.
« Last Edit: March 15, 2023, 08:06:54 AM by RBPLC »

BobO

  • Host Moderator
  • Hero Member
  • *****
  • Posts: 6170
  • Yes Pinky, Do-more will control the world!
Re: Timer Pandamonium!
« Reply #1 on: March 15, 2023, 09:11:28 AM »
Do you see any errors or warnings?
"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

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: Timer Pandamonium!
« Reply #2 on: March 15, 2023, 11:31:35 AM »
Make sure your Designer project matches what's in the PLC (the Write to PLC button will be ENABLED if they are out of sync).  We had a bug recently that we would try to do status after making modifications to UDTs on the Designer side, but were not yet written to the PLC (inconsistencies galore).

If that's not the case, if you are able, please email your project .dmd file to "support at hosteng.com" (you know what I mean) so we can try to duplicate it and hopefully address the issue.

RBPLC

  • Hero Member
  • *****
  • Posts: 586
Re: Timer Pandamonium!
« Reply #3 on: March 15, 2023, 12:39:20 PM »
Do you see any errors or warnings?

There are no errors or warnings. I was running this Program this morning and timer execution appears to be correct, despite wild monitored values.

RBPLC

  • Hero Member
  • *****
  • Posts: 586
Re: Timer Pandamonium!
« Reply #4 on: March 15, 2023, 12:48:51 PM »
Make sure your Designer project matches what's in the PLC (the Write to PLC button will be ENABLED if they are out of sync).  We had a bug recently that we would try to do status after making modifications to UDTs on the Designer side, but were not yet written to the PLC (inconsistencies galore).

If that's not the case, if you are able, please email your project .dmd file to "support at hosteng.com" (you know what I mean) so we can try to duplicate it and hopefully address the issue.

Project was fully written to the PLC. The screenshots posted are with full sync. I've tried to resolve in multiple ways. Including creating a new Program with the same logic, copying logic out of program and deleting all logic and copying it back in. I've tried to copy a TMR, delete the original and the copied version displays the same.

Additional Information: This started occuring after adding a .Bit to a UDT used in the Program. After adding the bit, I sorted the list to keep everything grouped to my liking (I suspect that this caused it). This morning I was trying to add an additional timer to the UDT and I was notified that I had exceeded the 64 dword limit of the UDT. After creating another UDT for this timer (as recommended by the popup) I put this timer in the Program and it displays normally. As stated, I suspect it's related to either the re-ordering of the UDT or being "close" to the dword limit of the UDT?

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: Timer Pandamonium!
« Reply #5 on: March 15, 2023, 12:57:23 PM »
Sounds like getting a copy of the project would help.

RBPLC

  • Hero Member
  • *****
  • Posts: 586
Re: Timer Pandamonium!
« Reply #6 on: March 15, 2023, 01:23:32 PM »
Sounds like getting a copy of the project would help.
I've just emailed the .dmd file. Disregard the mispelling and sub-standard programming.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: Timer Pandamonium!
« Reply #7 on: March 16, 2023, 09:43:13 AM »
There is a status issue with large structures doing status on a nested structure.  The data in the PLC is correct.

There is not an issue if you do status on the individual leaf elements, e.g. MyStruct42.MyTimer.Acc

Workarounds:
Also, the status for the entire large structure works - although it's so big, it gets clipped.  In Data View if you try MyStruct42.MyTimer doesn't give proper status.  But if you blow out the individual fields of the nested timer structures (right click on the MyStruct42.MyTimer in Data View and select Expand Structure), you get the proper status of the individual Timer fields.

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: Timer Pandamonium!
« Reply #8 on: March 16, 2023, 10:22:43 AM »
The issue you found came down to ONE bit in your UDT.  There was a bit added and the end, and it expanded the UDT to 64 DWORDs (256 bytes, layout dword:bit offset 63:0).  Since that UDT is so big, it utilizes a different path in Designer to do a different kind of status ("Bulk" status vs. "Simple" status).  The Designer logic currently does not handle substructures in a bulk status request.  Hence, the request ends up reading BYTEs from DWORD offset 0, not DWORD offset 52 in the parent UDT (52 is the DWORD offset wherever the timer is, 8 BYTEs - the size of a Timer).

So another workaround is to tweak your UDT to be 63 DWORDs long, not 64.  I tried it by moving that one bit as a union with another bit (not a valid change for working code, but just to tweak the UDT size from 64 down to 63 DWORDs).  The Timer status in Ladder and Data View worked.

So, if you have a spare bit anywhere else, you could move that one bit - but I see that you are probably not done in your definition of that UDT, so this may not be a valid workaround.  There is a limit of 64 DWORDs in a structure (256 bytes), so be judicious in your structure member expansion (you may need to create a 2nd UDT).

We are going to fix that bug in the next version of Designer.  It's definitely a Designer side issue - the PLC responded "properly" but with an "improper" request from Designer for that nested timer structure status.

One bit.  Ha!
« Last Edit: March 16, 2023, 10:26:07 AM by franji1 »

RBPLC

  • Hero Member
  • *****
  • Posts: 586
Re: Timer Pandamonium!
« Reply #9 on: March 16, 2023, 10:42:04 AM »
The issue you found came down to ONE bit in your UDT.  There was a bit added and the end, and it expanded the UDT to 64 DWORDs (256 bytes, layout dword:bit offset 63:0).  Since that UDT is so big, it utilizes a different path in Designer to do a different kind of status ("Bulk" status vs. "Simple" status).  The Designer logic currently does not handle substructures in a bulk status request.  Hence, the request ends up reading BYTEs from DWORD offset 0, not DWORD offset 52 in the parent UDT (52 is the DWORD offset wherever the timer is, 8 BYTEs - the size of a Timer).

So another workaround is to tweak your UDT to be 63 DWORDs long, not 64.  I tried it by moving that one bit as a union with another bit (not a valid change for working code, but just to tweak the UDT size from 64 down to 63 DWORDs).  The Timer status in Ladder and Data View worked.

So, if you have a spare bit anywhere else, you could move that one bit - but I see that you are probably not done in your definition of that UDT, so this may not be a valid workaround.  There is a limit of 64 DWORDs in a structure (256 bytes), so be judicious in your structure member expansion (you may need to create a 2nd UDT).

We are going to fix that bug in the next version of Designer.  It's definitely a Designer side issue - the PLC responded "properly" but with an "improper" request from Designer for that nested timer structure status.

One bit.  Ha!


Thanks for the response and deep dive franji. You answered my question concerning reducing the size. I haven't frequently bumped up to that UDT size limit (once before with dealing with strings) and had forgotten about that limitation. Since I was forced to create another UDT anyway, I'll move some things around. I thought it was related to the re-numbering I performed but it looks like it coincided with going over the dword boundary. I will say that having everything flashing all over the place and random values makes troubleshooting pretty difficult.

As I've posted before (this being tangentially related), when you start building large UDTs, it's nigh impossible to get all of the elements (or even most of them many times) defined in the batch processing method which is why I've requested direct and easy access to build out UDTs. 

franji1

  • Bit Weenie
  • Host Moderator
  • Hero Member
  • *****
  • Posts: 3843
    • Host Engineering
Re: Timer Pandamonium!
« Reply #10 on: March 16, 2023, 11:15:58 AM »
You hit the UPPER limit on the UDT size (256 Bytes/64 DWORDs), which coincided with the LOWER limit of a BULK DATA TRANSFER.  That combination is what did it.