Channels vs Ports

Scottpulman

Does anyone have any idea if there is any programming or run time beneficial relationship between channels and ports?

For example Is it better to have a higher channel count and less ports active or is it better to use a lower channel count and more ports?

Is there any difference between Wired, Wireless and R4's?

Just something that I am thinking about, always trying to improve my code.

DHawthorne

There is a memory hit with more ports, but honestly, it's so small I never worry about it. I just use as many ports as is convenient. You might want to make an effort not to skip a lot of port numbers ... it will allocate memory for the unused in-between ports as well. Again, it's not a big deal, but it's pure waste. I still do it sometimes, just to group my port numbers in a way that leaves room to grow and keep like devices together, but be careful. If you have stuff on ports one and 1000, 2-999 will also get allocated. It's not such a big deal if you have 1 and five, but bigger gaps are bigger chunks of memory.

PhreaK

I'm not to sure about a performance hit with higher channel / port numbering (might be interesting to do some testing on).

As DHawthorne mentioned though there is a definite memory penalty associated with assigning higher port/channel numbering. You can brick an x100 series master by attaching a touch panel to it with nothing but a single button on a high port/channel (can't remember specific numbers).

John Nagy

Ports v. Channels v. Reuse

Many dealers are surprized at the speed of the touch panel response in our CIneTouch product considering that it can control up to 50 rooms and 50 sources on one master. Even AMX techs have asked how we do it so quickly. It may have to do with this discussion - we use only 2 ports for all source activity, and only channels up to 256. We do this for compatibility with R4, IR, MIO-DMS, PLK-DMS, G3 panels, etc.

We accomplish this economy by reusing the same button channel for PLAY for every device of every kind. We detect that a PLAY (1,1) arrived from a UI, determine the source in use, and send the command corresponding to PLAY to that source.

In a typical system including, say, 5 sat receivers, a standard way to do panels is to create 5 sets of sat pages, each pointing to one sat. It's convenient to keep the channel numbers the same for similar commands, so many programmers differentiate the pages by assigning a PORT to each source... so play is 1,1 for Sat 1, and a 2,1 would mean it was for Sat 2, etc.

We decided to do our lookup method to be able to use the same pages for any device, so the same touch panel can be used in any system, regardless of how many sources... without editing. It appears to also be a LOT faster on large systems. It may be because of so few PORTS in use. Or that may be part of it, anyway. It saves on memory as a side effect.

the8thst

I do the same thing for all of my source control as well. My standard system (audio distribution, video distribution, weather, source control, security) is only 4 ports. Regardless of the number of 1-way controlled source components (satellite, cable, bluray, etc).

It really makes it easy to use the same frameworks and touch panel files for all of our jobs.

a_riot42

John Nagy wrote: »

Many dealers are surprized at the speed of the touch panel response in our CIneTouch product considering that it can control up to 50 rooms and 50 sources on one master.

I haven't found ports to have any signiificant effect on latency and I haven't found the number of zones or sources to either. From my experience latency generally is a function of how much code has to run after a button press and how much code is in define_program, and any IO required like reading/writing from files. Using a database to do lookups would add some latency I would think, especially if you are using so few channel numbers in a system with many sources/zones since every button press requires the lookup of the device, zone, user etc before the command can be executed. I have also found latency to increase substantially once complicated nested structures are used but that's a seat of the pants observation.
Paul

jjames

a_riot42 wrote: »

I haven't found ports to have any signiificant effect on latency and I haven't found the number of zones or sources to either.

Agreed. I go well above the 256 mark John is talking about, however keeping it that low is actually a good idea for compatibility if you have a mixed project of G3 & G4 products. I also cannot agree more that the efficiency of your DEFINE_PROGRAM is quite important. In past jobs, I'd have all my feedback in DEFINE_PROGRAM, however in my most recent job, I moved all my feedback into functions which are only called when needed (i.e. after a button press), and it was definitely needed considering the size of the job.

It's funny how your code morphs over the years and you find new "tricks" to make it better. The 256 limit CT implements is not something I've consciously thought about, but really does make sense.

John Nagy

Define_...

The CT DEFINE_PROGRAM is a single line evaluating the state of the license on start. Everything else is event driven.

ROO

TP ports & channels

Hi all,
I was investigating the impact of ports and channels on TP a couple of years back, and was told by Tech support that the Ports are allocated 10 at a time. For each Port you get 4000 button numbers. So I try to stay within the first 10 ports, and use the ports to separate major device types and separate devices with an offset. Since we mostly use the NI3100, the processor speed for calculating an offset is really minimal ( within milliseconds per button push). The reaction of the Touch Panel seems to be more affected by the amount of memory the graphics take up.

If this isn't correct anymore, I'm sure someone in AMX will correct me.
Good luck
ROO