Home AMX User Forum AMX Control Products

ports or codes extension

I usually use different ports in tpd4 file per device so that i can start each codes of the device from 1. I want to know if this is a good practice since sometimes due to the amount of devices, the ports have grown up to 60 but i may be using only 50 functions per device. Which process is processor intensive?

Comments

  • jjamesjjames Posts: 2,908
    The processor must allocate memory for all 60 ports. So, think of a larger system of 20 touch panels. That'd be 1,200 ports it needs to allocate resources / memory for - a bit excessive in my opinion.

    I've *never* been a fan of using different ports for different devices. Below is how do control devices; something like this will allow you to expand your system without having to grow very much code, especially in the control portion. When I leave a job I want to be able to expand it, if the client requests, with minimal changes. This is not only beneficial to the client because it won't take very long, but for the company as well. If I have to add two more cable boxes, I modify two structure in my code and I'm done; I don't have to change anything in the panel in terms of the control side of things.

    Zone, and Panel are both structures that store important information and are modified prior to this section of code being used.
    button_event[dv_tp,i_tpBtns_transport]	// Source Transport Buttons
    {
    	push:
    	{
    		stack_var integer i_panel;
    		stack_var integer i_index;
    		stack_var integer i_zone;
    		stack_var dev dvDevice;
    		
    		i_panel = get_last(dv_tp);
    		i_index = button.input.channel;
    		i_zone = Panel[i_panel].i_controlledZone;
    		
    		dvDevice = Zone[Panel[i_panel].i_controlledZone].dv_controlled;
    		
    		switch(Panel[i_panel].i_controlledSource)
    		{	
    			// Control Roku
    			case i_src_roku:
    			case i_src_sat:
    			case i_src_cable:
    			case i_src_game:
    			case i_src_music_cab:
    			case i_src_bdp:
    			case i_src_iPod:
    			{
    				if(dvDevice != 0:0:0)
    					to[dvDevice,i_index];
    			}
    			
    			case i_src_tuner1:
    			{
    				// Control serial devices
    			}
    			
    			case i_src_xm2:
    			{
    			
    			}
    			
    			default:{} // No source - no control
    		}
    	}
    }
    
  • viningvining Posts: 4,368
    If i had it to do over again i would scrub the port per device method too. I could probably change over fairly easy by replacing the individual button events with functions but the idea of doing all that work isn't appealing at this point. I wish i knew then what i know now. Of course i probably would have stayed away from AMX altogether then and had a life.
  • I use separate ports for devices that generally have the same interface in every system, so that I can use modules for the UI programming. However I don't think I've ever had more than 10 ports on a single touch panel, and rarely even get past 5. My mind boggles at a system where one touch panel is controlling 60+ devices directly.
  • I use a port for AV switching/source selection/zone power on-off/volume.
    1 for 1-way controlled devices (cable box, satellite, bluray, appletv, etc)

    and then 1 per sub system or devices with 2-way feedback (security, lights, sirius, kscape, etc).

    My typical projects are around 6 - 11 ports per touch panel - and these are full distributed a/v systems that are anywhere from 8-36 rooms of audio and 8-16 video displays.
  • ericmedleyericmedley Posts: 4,177
    I beat my head on the port per device wall for a while. But a lot of the projects I had at the time required a ton of devices and I had that beaten out of me real fast. The way I ended up doing it was using a single port for all devices (I deviced them into what I called sources and environments)

    I tried to follow AMXs conventions on standard buttons, Like 'Play' is channel 1, etc....

    I then tracked what panel was controlling what device in code. It made everything so much simpler over time. Adding a new device became rather easy. The device-by-port method ran out of room pretty fast and you were'nt really organizing/consolidating code never really happened.

    Like Vining, I wish I knew then what i knew now. I hear that a lot...
  • samossamos Posts: 106
    I usually use one port per device and one port for the logic that is specific to the system I am programming, that way I can reuse code for device control. I see the concern of memory allocation, but i very rarely have a system with more that 3 touch panels so memory is not my major concern. If I did have a system with lost of panels I may not write the code that way. In the end there is no wrong or right way just your way and as long as it works and save you time the next time you do it then go for it. Just my 2 cents.
  • a_riot42a_riot42 Posts: 1,624
    the8thst wrote: »
    I use a port for AV switching/source selection/zone power on-off/volume.
    1 for 1-way controlled devices (cable box, satellite, bluray, appletv, etc)

    and then 1 per sub system or devices with 2-way feedback (security, lights, sirius, kscape, etc).

    My typical projects are around 6 - 11 ports per touch panel - and these are full distributed a/v systems that are anywhere from 8-36 rooms of audio and 8-16 video displays.

    I do the exact same thing. I've never encountered any issues doing it this way.
    Paul
  • chillchill Posts: 186
    I've NEVER liked this port-per-device thing, nor have I ever done systems like that. I always figured it must be what they're teaching at AMXU these days, since I see it so much in other people's code. But to my mind, it creates complexity and extra work. There are a few edge cases where it could be beneficial, but generally it's not good. Your mileage may vary.
    .
  • viningvining Posts: 4,368
    chill wrote: »
    I've NEVER liked this port-per-device thing, nor have I ever done systems like that. I always figured it must be what they're teaching at AMXU these days, since I see it so much in other people's code. But to my mind, it creates complexity and extra work. There are a few edge cases where it could be beneficial, but generally it's not good. Your mileage may vary.
    .
    I think it's much easier for new programmers to jump it and get systems working since you don't have to manage anything per sei, you don't need to determine the page you're on, what feedback to send or what code to execute based on a common button/port type of program. It is really more plug & play and all you really need to do is "find & replace" to change the ports on a dev's UI to include it.

    The problem is once you go down the easy path and then realize the benefits that are available on the path less taken it's hard to convert. Quite frankly when I started out I was only exposed to PI & PII, didn't know about this forum and had no other programmers to learn from and the single port approach never dawned on me and probably would have been over my head. Still is a little bit. :)
  • 1-port for each device type works for me. I've had +50 panels with ~30 ports defined on each hosted off a single NI-3100 without issue.
  • ColzieColzie Posts: 470
    the8thst wrote: »
    I use a port for AV switching/source selection/zone power on-off/volume.
    1 for 1-way controlled devices (cable box, satellite, bluray, appletv, etc)

    and then 1 per sub system or devices with 2-way feedback (security, lights, sirius, kscape, etc).

    +1

    (and some characters)
  • PhreaKPhreaK Posts: 966
    I tend to use one port per logical interface. Ideally, each touch panel is designed as a cohesive interface or a set of these (ie primary operational interface, hidden tech staff interface etc), not discreet device controls that have been bundled together. This allows for nice clean separation of different parts of your UI code as well as UI components within your tp4 file, which in turn simplifies debugging and makes it much easier for multiple developers to collaborate without conflicts. It also enables you do things like split out the tech interface onto a wireless panel or mobile device using TPControl very easily.

    Performance wise I don't have an understanding of what happens in the firmware layer but from my observations I have not noted any significant performance penalty / benefit with either of theses approaches. However, any impact would likely be more memory intensive rather than processing intensive.

    That all being said the framework is there and flexible enough to allow you to utilize whatever approach works best for you and the developers that you work with. Just for the love of all things good if you are going to use one approach at least stick to it for that entire project.
  • Based on the feedback, i rebuilt my code which had about 60 tp ports to only port 1. Now how do i check if its less memory intensive or processor intensive. I tried checking cpu usage and it has reduced. Is there anyother way to check.
Sign In or Register to comment.