Feedback to TP's
![[Deleted User]](https://wd.vanillicon.com/v2/df3d70efbb2d143e586954b0ddbf425d.svg)
[Deleted User]
Posts: 0
I have been setting the feedback on TP's via a timeline that evaluates every 10th of a second, I have found that this seems more efficient than using the define program section for [TP1[1],1]= vTheatreDeviceSelect[1]=1 etc.. The house I'm working on has 13 MVP Panels and am finding feedback issues when there is alot going on in the house specifically level feedback for volumes. I have further streamlined this method by only updating the panel that is controlling the volume.
My question is whether defining a Virtual device per TP and then Combining it with the Phsycal TP is a more efficient way of providing the feedback, and would require less of the processor since I am only updating a virtual device at a change and not every 10th of a second.
My question is whether defining a Virtual device per TP and then Combining it with the Phsycal TP is a more efficient way of providing the feedback, and would require less of the processor since I am only updating a virtual device at a change and not every 10th of a second.
0
Comments
If I understand your suggestion correctly, you are going to combine all 13 of your touchpanels with a virtual panel and perform all feedback operations on the virtual panel. This of course assumes all touchpanels are identical and use the same port/channel layout but if this is the case, then it is certainly more efficient from a code point of view. Instead of 13 different feedback statements (one to each TP), you can do one instead for each button feedback you want to provide. From a Netlinx interpreter point of view, this is more efficient. However, the Master still has to send messages to each of the touchpanels combined to the virtual device so the Master still has roughly the same amount of processing work to do with regards to the button or level feedback at least based on my understanding of how it works.
I too have several projects with a large number of touchpanels but I can't combine them since all panel files are slightly unique. There are several optimizations I have made one of which is similar to your own except I chose not to use a TIMELINE to implement it.
1. Only send feedback to panels that are ONLINE and awake - the Master may optimize this anyway but if a panel is not awake or offline, I ignore it in my feedback loop for channels, levels, and variable text strings. I have ONLINE handlers for all panel port combinations that refresh a panel when it comes ONLINE or it is awakened.
2. I optimize feedback handling in Mainline (DEFINE_PROGRAM) using a WAIT to turn on a variable called nFeedback (this is done in each Module that provides feedback). When the WAIT triggers (could be 1/10th second or 1 second depending on what I specify), the nFeedback variable is set to 1 and the feedback statements within an IF(nFeedback) are executed. The last step of the feedback block is to set the variable to 0. In this manner, I can throttle the frequency of the feedback statements in each module separately without the overhead of the TIMELINEs.
Without some control over the frequency of feedback, projects with large numbers of touchpanels that require a lot of channel, level, and vartext feedback can perform very sluggish so those are techniques I have used to try to make the program more efficient.
I too would be interested in other techniques used by programmers to optimize feedback and processing in their code.
Thanks Reece,
This is essentially what I am doing now. Essentially if a Virtual Device never goes offline then in updating levels channels etc. on this device, in theory then when ever the Physical Device comes online then it should be bought up to date if it is combined with the virtual device.
In monitoring the traffic between the NI and the MVP, there seems to be alot of traffic in updates, so I'm wondering if this is the most optimum way of proceding.
In answering, yes all of the MVP's are slightly different, and most feedback is being updated individually but some globally. My thought is to have a Virtual device per MVP and just update each Virtual.
I use the timeline method usually, but I bump it back to once a second rather than a tenth. That is generally more than fast enough of a refresh (but the beauty of timelines is you only need to tweak one variable to change the interval). I also set flags based on the type of feedback I am displaying. For example, I set a flag that a panel just turned on the lighting page, and only send lighting feedback when that flag is high.
However, all of this only really matters for SEND_COMMANDs for things like variable text fields. The NetLinx master tracks channels and buttons internally, and only tells the panel to change them if they have in fact changed. Putting a line like [dvPanel, Butn1] = (condition1) in mainline is no different from putting it in a timeline; it only gets sent when condition1 changes.
This is related I think...I'm not well-versed in use of virtuals & combines.
I have a new installation of an MVP in a theater. A bargraph/level on the TP passes any input to a separate level on the RS232 port device. (I do this since vol can also be controlled by DMS.)
When the MVP goes to sleep, the level checks out to zero and the volume goes there too.
Would making a virtual of the TP and combining help here? I'm just assuming that the MVP will still indicate a level of 0 when it goes offline and the virtual will match that.
Or should the level event check whether the panel is online before triggering the rs232 event?
Thanks for any guidance.
-Bill
to answer this, this is a well known problem (at least for me
the way we solved this is the following: add a channel code to all your level slider (can be the same, doesnt really matter) and in your code do this:
(* if one of the levels is changed, we enable this var *)
(* so when the panel goes offline, it doesnt kill our levels *)
BUTTON_EVENT[dvTP, 500]
{
PUSH:
ON[nLevelActive]
RELEASE:
OFF[nLevelActive]
}
then for your level event:
(* LightLevel *)
LEVEL_EVENT [dlLightLevels]
{
// CHeck if Level is pushed
IF (nLevelActive)
{
to answer this, this is a well known problem (at least for me
the way we solved this is the following: add a channel code to all your level slider (can be the same, doesnt really matter) and in your code do this:
(* if one of the levels is changed, we enable this var *)
(* so when the panel goes offline, it doesnt kill our levels *)
BUTTON_EVENT[dvTP, 500]
{
PUSH:
ON[nLevelActive]
RELEASE:
OFF[nLevelActive]
}
then for your level event:
// LightLevel
LEVEL_EVENT [dlLightLevels]
{
// Check if Level is pushed
IF (nLevelActive)
{
// do your stuff here
}
}
this should work, because now your levels are only updated when the slider is actually pushed, and changed, not only when its changed
----
to reply to the topic starters question:
why dont you create a device array of your touchpanels? this way you can 'see' which touchpanel triggered an event and can act according to this, so you'r only updating the panels that are active...
EDIT:
i see you are using an array right?