Panel Locking up

JOHNBONZ

I created a calendar app that lists all days in a year, to paint to touch panel. So I have a for loop that loops thru about 420 times -no SEND_STRINGS, only painting screen with numbers to fill in a calendar --- so sometimes I see this from one of my 8400 touch panels(I have 7 panels - the others don't seem to have this issue) and the panel freezes as it is painting screen. Then after a minute or so, it goes to main page, which frees it up.

What causes this? How do I reset this value? Is there a way programmatically to rest this queue?

This panel has: file system 256MB


Line 92 (17:59:28):: Memory Available = 27510584 <10016>
Line 93 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 200
Line 94 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 225
Line 95 (17:59:28)::
Line 96 (17:59:28):: Memory Available = 27499944 <10640>
Line 97 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 250
Line 98 (17:59:28):: Memory Available = 27489624 <10320>
Line 99 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 275
Line 100 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 300
Line 101 (17:59:28):: Memory Available = 27479384 <10240>
Line 102 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 325
Line 103 (17:59:28)::
Line 104 (17:59:28):: Memory Available = 27469304 <10080>
Line 105 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 350
Line 106 (17:59:28):: Memory Available = 27459144 <10160>
Line 107 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 375
Line 108 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 400
Line 109 (17:59:28):: Memory Available = 27448904 <10240>
Line 110 (17:59:28)::
Line 111 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 425
Line 112 (17:59:28):: Memory Available = 27438744 <10160>
Line 113 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 450
Line 114 (17:59:28):: Memory Available = 27428584 <10160>
Line 115 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 475
Line 116 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 500
Line 117 (17:59:28):: Memory Available = 27418344 <10240>
Line 118 (17:59:28)::
Line 119 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 525
Line 120 (17:59:28):: Memory Available = 27408264 <10080>
Line 121 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 550
Line 122 (17:59:28):: Memory Available = 27398024 <10240>
Line 123 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 575
Line 124 (17:59:28):: (Reader=ICSPTCP1 writer=tIPConMgr)- CMessagePipe::Max = 600
Line 125 (17:59:28):: Memory Available = 27387864 <10160>
Line 126 (17:59:30):: Optimizing ICSPTCP1 messages with 600 messages in queue.
Line 127 (17:59:30):: Optimization ICSPTCP1 complete with 600 messages now in queue. 0 messages avoided.
Line 128 (17:59:30):: CMessagePipe::Write ICSPTCP1 (PipeReader) this=0x01E66558 has 600 Messages in queue (Deleting & Ignoring1)

John Nagy

The outbound message queue gets backed up when you push data out faster than it is taken up by the panel(s). This happens if you have a lot to say but the panel goes offline from the overload while you say it (or before).

It would appear that you are crashing the panel with too much, too fast (even presuming the content of your commands are accurate). The panel probably goes offline, or at least cannot keep up, then the rest of your commands stack up and are either purged or sent after the panel is no longer interested.

Try putting some time between all your commands, and/or combining them into chunks to prevent overwhelming the target panel (wifi panels are more likely to need the time...)

nicholasjames

Queues and Thresholds explained

I'd recommend absorbing Tech Note #824 - "Queues and Thresholds explained". I actually have the graphic from the end of that Tech Note pinned to my wall. (#264 - "Threads in NetLinx" is also a good one)

Besides the touchpanel, pushing out that many messages in that amount of time isn't a great idea for the rest of your program either. It's important to keep in mind that sending a message to any device has to share space and time with every other message. Those 600 messages in 1 second doesn't just put a strain on the touchpanel, but it slows up the processing of messages for every other sub-system as well. This can mess with timed events like Wait, Hold, or Timelines. While the system is busy trying to process all those messages, time is just ticking away. Once NetLinx (the "Interpreter") gets around to checking the Wait Lists (see #264) enough time has passed that it may be firing off one too many timed events at once.