More wonkiness with combined panels

DHawthorne

I've run across a bit of a problem, and am hoping there is some mechanism I can apply that won't require me re-wiriting a lot of code.

A customer recently asked that I give him a one-page summary of what all his systems are doing, and the ability to turn them on or off from it. The system in question consists of five masters, two of which control one-room theaters, and two more that control multiple room theater or TV's. So I made a grid showing each possible viewing station and the sources available to each. The local systems track what each is doing via channels on a virtual device, and resond to SEND_COMMANDS on the same device. These virtuals are defined on each master so they can all talk to each other. This part of it works fine. The problem is in the panel. Since this "snapshot" is going to be the same everywhere, depending on what is going on, I linked it to a single virtual device, which in turn is combined on a central master with an array of all the touch panels. As far as that goes, this works fine too. Here is what the panel looks like normally with the HD DSS on in the Basement Theater:



The problem is when a panel gets rebooted. If I update the panel file, or the network burps and a panel goes offline, when it comes back, the feedback channels on this shared page are not accurate. It's almost like random feedback channels are turned on (the following picture is from TPD4, not a live shot, the channels aren't exactly the ones that come on, this is just the general idea):



I'm guessing that the internal mechanism that updates feedback channels is only tracking their state in the virtual. This prevents it from updating them on a panel that went offline and came back again; it doesn't see they need it. What boggles me is that they don't instead just revert to the panel defaults (all off), and that it doesn't affect every channel. There are only two ways for me to synchronize them - reboot the master, or go through every system and turn ON each source that has a falsely lit button, then turn it off again.

I'm afraid I have to abandon the combine, unless there is some obscure command that will force an update. I tried uncombining that virtual and re-combining it on any online event for the effected panels, and that brought the system to it's knees. The panels went into an endless offline/online cycle; I guess there was just too much traffic generated on the network. Eliminating the combine will add quite a bit of work - this isn't the only page that is a part of that combine, I have several feedback elements using it (and they all have similar problems). I'm also not certain I won't just see the same thing if I simply talk to the array instead of the virtual (though I guess that would be the easiest to try). What I really want to avoid is needing to individually update each panel.

Any ideas?

alexanbo

Not sure if all your touchpanels talk to the same master but if they do I might just create a timeline with the feedback in it.

The timeline event would then look something like this:

{
[dvTP_ARRAY,1] = [vdvDEV,1]
[dvTP_ARRAY,2] = [vdvDEV,2]
}

Then you don't have to worry about stuff going offline as it would be refreshed depending on how often you fire the timeline.

frthomas

No ideas.

In my experience, I found that whenever a panel comes online, you have to refresh it. All of it. Every time. And that COMBINE was not a tool you could use for any serious panel like what you are trying to achieve.

Refreshing needs to be done S-L-O-W-L-Y otherwise AXLink goes nuts. I found the limit to be about 100 refreshes and then 0.5 secs of pause or something like that. My panels have a "please wait" page as initial page. The last thing the refresh does is to move the panel to the correct page (which depends on whatever the system is up to at that time). Voila panel never shown "undressed" from user, no matter what ONLINE/OFFLINE comes around.

I found that the same code worked as well for fixed panel (to cater for the inevitable power down with the master up) than for wireless panels (for which the code was designed in the first place).

This being so common, it came to me as a surprise that AMX did not build some hooks for such a management in Netlinx.

HTH

Fred

DHawthorne

alexanbo wrote:

Not sure if all your touchpanels talk to the same master but if they do I might just create a timeline with the feedback in it.

The timeline event would then look something like this:

{
[dvTP_ARRAY,1] = [vdvDEV,1]
[dvTP_ARRAY,2] = [vdvDEV,2]
}

Then you don't have to worry about stuff going offline as it would be refreshed depending on how often you fire the timeline.

That's one of the things I am uncertain about - feedback channels are tracked by the master and don't update no matter how many times you explicity change them, if the master doesn't think they need to be changed. Obviously, in my case it's tracking the virtual. I'm not certain at all that sending essentially the same updates directly to the arrayed panels will make a difference. I suppose it's the next thing I can try, else I'm going to have to go for the kind of approach Fred suggested, which is exactly what I'm trying to avoid. This system is tracking a huge amount of stuff as it is. It really should be able to handle it, and in my view, the same way channels are tracked by the master, it should automatically send updates on combined devices that go on and off line. I find I am continually writing code to work around shortcomings that really ought to have been dealt with on a much lower level.

frthomas

DHawthorne wrote:

I suppose it's the next thing I can try, else I'm going to have to go for the kind of approach Fred suggested, which is exactly what I'm trying to avoid.

Uh? It only takes a couple of months to write some very nice generic mechanism :-)

Fred

DHawthorne

frthomas wrote:

Uh? It only takes a couple of months to write some very nice generic mechanism :-)

Fred

It would if this combined panel was dedicated to this function. I'm miserly with assigning new ports; everything in the system that could be combined uses the one port, so I would have to go to each of them and convert them as well. Some are in modules like this one, and others in the main master file itself. And it isn't really the time or effort doing so - it's the fear that I'll miss something, or introduce some unexpected side effect. This is a project that has been in service for two years, and the core of which was written 3 years ago - it's evolved a lot, and a good deal of that early work had no benefit of experience behind it.

Perhaps a compromise, and a new port just for this is in order.

GSLogic

In a combine panel situation: I store all panel locations in an array, so when a panel falls offline, I still have the location stored in an array. Now when the panel comes back online, I check to see where it was before going offline and then trigger the appropriate functions to re-combine and update the panel to the current settings. I also check to see if the section the panel is going to be updated with is still active or has another panel has turned off that section, if this is the case then just send the panel to the main menu.

By section I mean: Theater Room / Security / Lighting / etc.