NI-4100 locks up when panel goes online
mludviksen
Posts: 18
Hi. I've searched around here for clues as to what might be going on, but I've come up empty. Basically, I've got a system with 13 panels, and I've got modules for AudioReQuest, VideoReQuest, Polk Audio XM, Vantage Lighting, Security Cameras, Aprilaire HVAC, etc. I'm running an NI-4100 with v.3.21.354, and the latest device firmware too. I was running a slightly older version when this started happening and upgraded hoping that would fix it - it didn't.
Anyway, I can consistently reproduce the problem... I have 3 MVP-8400's and everything works fine if I pull the batteries out of one of them (preventing it from going online) before the controller boots up. Here's how things look before I put the batteries into the last MVP:
'Volatile Free' is my problem - it quickly goes to zero (or close to zero) when the last MVP is allowed to come online. Does the amount of 'Volatile Free' seem unusually low for a system of this size? Doesn't the NI-X100 series have twice the RAM of the older units? Anyway, here's what happens when the last panel comes online:
As a result, the controller completely locks up, since it basically has no available 'Volatile Free'. When the last panel starts to come online, here's what the notifications show:
Does anybody see anything strange here that I'm missing? Any kind of hint would be *much* appreciated... I'm at a complete loss as to what's going on here. I've been 'updating' my panels to a new design that's quite a bit different, and somehow it seems to be related. If I leave the 'old' design on the MVP and let it boot up, 'Volatile Free' drops by about 1.1MB - not enough to bring the server down. The 'new' design must drop the RAM by more than that. I also tried to 'remove user pages' from the MVP and let it boot - and it only dropped the RAM by 35KB! Seems to be related to the panel file somehow. I have also been able to bring the system down with a CV-7 - so it's not specific to the MVP's (although I did do a 'save as' panel type from the MVP panel file). I've checked my online events and there's nothing I see that would eat up the RAM like that. Maybe the system can handle 12 panels 'as is', but the 13th is too much?
Thanks in advance for your comments and suggestions.
Regards,
Mark
Anyway, I can consistently reproduce the problem... I have 3 MVP-8400's and everything works fine if I pull the batteries out of one of them (preventing it from going online) before the controller boots up. Here's how things look before I put the batteries into the last MVP:
>show mem Volatile Free : 1590336 (largest free block in bytes) NonVolatile Free: 930360 (bytes free) Disk Free :120852480 (bytes of free space) Duet Memory Free : 975708 (bytes) Partition 1 - 975708 (bytes) Partition 2 - <UNKNOWN>
'Volatile Free' is my problem - it quickly goes to zero (or close to zero) when the last MVP is allowed to come online. Does the amount of 'Volatile Free' seem unusually low for a system of this size? Doesn't the NI-X100 series have twice the RAM of the older units? Anyway, here's what happens when the last panel comes online:
>show mem Volatile Free : 18336 (largest free block in bytes) NonVolatile Free: 930360 (bytes free) Disk Free :120852480 (bytes of free space) Duet Memory Free : 975708 (bytes) Partition 1 - 975708 (bytes) Partition 2 - <UNKNOWN>
As a result, the controller completely locks up, since it basically has no available 'Volatile Free'. When the last panel starts to come online, here's what the notifications show:
Line 3904 :: Command To [10506:1:1]-[LEVON] - 09:49:54 Line 3905 :: Command To [10506:1:1]-[RXON] - 09:49:54 Line 3906 :: Command To [10506:4:1]-[LEVON] - 09:49:54 Line 3907 :: Command To [10506:4:1]-[RXON] - 09:49:54 Line 3908 :: Feedback:On [10506:4:1] - Channel 2 - 09:49:54 Line 3909 :: Output Channel:On - From [10506:4:1] - Channel 2 - 09:49:54 Line 3910 :: Feedback:On [10506:4:1] - Channel 24 - 09:49:54 Line 3911 :: Output Channel:On - From [10506:4:1] - Channel 24 - 09:49:54 Line 3912 :: Feedback:On [10506:4:1] - Channel 44 - 09:49:54 Line 3913 :: Output Channel:On - From [10506:4:1] - Channel 44 - 09:49:54 Line 3914 :: Feedback:On [10506:4:1] - Channel 147 - 09:49:54 Line 3915 :: Output Channel:On - From [10506:4:1] - Channel 147 - 09:49:54 Line 3916 :: Feedback:On [10506:4:1] - Channel 151 - 09:49:54 Line 3917 :: Output Channel:On - From [10506:4:1] - Channel 151 - 09:49:54 Line 3918 :: Feedback:On [10506:4:1] - Channel 158 - 09:49:54 Line 3919 :: Output Channel:On - From [10506:4:1] - Channel 158 - 09:49:54 Line 3920 :: Output Channel Count [10506:1:1] - 622 - 09:49:54 Line 3921 :: Level Count [10506:1:1] - 268 - 09:49:54 Line 3922 :: Level Size [10506:1:1] - Level 1 Supported Types=BYTE,CHAR,INTEGER,SINTEGER,ULONG,LONG,FLOAT,DOUBLE,Unknown - 09:49:54 Line 3923 :: String Size [10506:1:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3924 :: Command Size [10506:1:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3925 :: Output Channel Count [10506:2:1] - 622 - 09:49:54 Line 3926 :: Level Count [10506:2:1] - 268 - 09:49:54 Line 3927 :: String Size [10506:2:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3928 :: Command Size [10506:2:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3929 :: Output Channel Count [10506:3:1] - 622 - 09:49:54 Line 3930 :: Level Count [10506:3:1] - 268 - 09:49:54 Line 3931 :: String Size [10506:3:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3932 :: Command Size [10506:3:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3933 :: Output Channel Count [10506:4:1] - 622 - 09:49:54 Line 3934 :: Level Count [10506:4:1] - 268 - 09:49:54 Line 3935 :: Level Size [10506:4:1] - Level 266 Supported Types=BYTE,CHAR,INTEGER,SINTEGER,ULONG,LONG,FLOAT,DOUBLE,Unknown - 09:49:54 Line 3936 :: Level Size [10506:4:1] - Level 267 Supported Types=BYTE,CHAR,INTEGER,SINTEGER,ULONG,LONG,FLOAT,DOUBLE,Unknown - 09:49:54 Line 3937 :: Level Size [10506:4:1] - Level 268 Supported Types=BYTE,CHAR,INTEGER,SINTEGER,ULONG,LONG,FLOAT,DOUBLE,Unknown - 09:49:54 Line 3938 :: String Size [10506:4:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3939 :: Command Size [10506:4:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3940 :: Output Channel Count [10506:5:1] - 622 - 09:49:54 Line 3941 :: Level Count [10506:5:1] - 268 - 09:49:54 Line 3942 :: String Size [10506:5:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3943 :: Command Size [10506:5:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3944 :: Output Channel Count [10506:6:1] - 622 - 09:49:54 Line 3945 :: Level Count [10506:6:1] - 268 - 09:49:54 Line 3946 :: String Size [10506:6:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3947 :: Command Size [10506:6:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3948 :: Output Channel Count [10506:7:1] - 622 - 09:49:54 Line 3949 :: Level Count [10506:7:1] - 268 - 09:49:54 Line 3950 :: String Size [10506:7:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3951 :: Command Size [10506:7:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3952 :: Output Channel Count [10506:8:1] - 622 - 09:49:54 Line 3953 :: Level Count [10506:8:1] - 268 - 09:49:54 Line 3954 :: String Size [10506:8:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3955 :: Command Size [10506:8:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3956 :: Output Channel Count [10506:9:1] - 622 - 09:49:54 Line 3957 :: Level Count [10506:9:1] - 268 - 09:49:54 Line 3958 :: String Size [10506:9:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3959 :: Command Size [10506:9:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3960 :: Output Channel Count [10506:10:1] - 622 - 09:49:54 Line 3961 :: Level Count [10506:10:1] - 268 - 09:49:54 Line 3962 :: String Size [10506:10:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3963 :: Command Size [10506:10:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3964 :: Output Channel Count [10506:11:1] - 622 - 09:49:54 Line 3965 :: Level Count [10506:11:1] - 268 - 09:49:54 Line 3966 :: String Size [10506:11:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3967 :: Command Size [10506:11:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3968 :: Output Channel Count [10506:12:1] - 622 - 09:49:54 Line 3969 :: Level Count [10506:12:1] - 268 - 09:49:54 Line 3970 :: String Size [10506:12:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3971 :: Command Size [10506:12:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3972 :: Output Channel Count [10506:13:1] - 622 - 09:49:54 Line 3973 :: Level Count [10506:13:1] - 268 - 09:49:54 Line 3974 :: String Size [10506:13:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3975 :: Command Size [10506:13:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3976 :: Output Channel Count [10506:14:1] - 622 - 09:49:54 Line 3977 :: Level Count [10506:14:1] - 268 - 09:49:54 Line 3978 :: String Size [10506:14:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3979 :: Command Size [10506:14:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3980 :: Output Channel Count [10506:15:1] - 622 - 09:49:54 Line 3981 :: Level Count [10506:15:1] - 268 - 09:49:54 Line 3982 :: Level Size [10506:15:1] - Level 1 Supported Types=BYTE,CHAR,INTEGER,SINTEGER,ULONG,LONG,FLOAT,DOUBLE,Unknown - 09:49:54 Line 3983 :: String Size [10506:15:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3984 :: Command Size [10506:15:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3985 :: Output Channel Count [10506:16:1] - 622 - 09:49:54 Line 3986 :: Level Count [10506:16:1] - 268 - 09:49:54 Line 3987 :: String Size [10506:16:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3988 :: Command Size [10506:16:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3989 :: Output Channel Count [10506:17:1] - 622 - 09:49:54 Line 3990 :: Level Count [10506:17:1] - 268 - 09:49:54 Line 3991 :: String Size [10506:17:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3992 :: Command Size [10506:17:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3993 :: Output Channel Count [10506:18:1] - 622 - 09:49:54 Line 3994 :: Level Count [10506:18:1] - 268 - 09:49:54 Line 3995 :: String Size [10506:18:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3996 :: Command Size [10506:18:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 3997 :: Output Channel Count [10506:19:1] - 622 - 09:49:54 Line 3998 :: Level Count [10506:19:1] - 268 - 09:49:54 Line 3999 :: String Size [10506:19:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4000 :: Command Size [10506:19:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4001 :: Output Channel Count [10506:20:1] - 622 - 09:49:54 Line 4002 :: Level Count [10506:20:1] - 268 - 09:49:54 Line 4003 :: String Size [10506:20:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4004 :: Command Size [10506:20:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4005 :: Output Channel Count [10506:21:1] - 622 - 09:49:54 Line 4006 :: Level Count [10506:21:1] - 268 - 09:49:54 Line 4007 :: String Size [10506:21:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4008 :: Command Size [10506:21:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4009 :: Output Channel Count [10506:22:1] - 622 - 09:49:54 Line 4010 :: Level Count [10506:22:1] - 268 - 09:49:54 Line 4011 :: String Size [10506:22:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4012 :: Command Size [10506:22:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4013 :: Output Channel Count [10506:23:1] - 622 - 09:49:54 Line 4014 :: Level Count [10506:23:1] - 268 - 09:49:54 Line 4015 :: String Size [10506:23:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4016 :: Command Size [10506:23:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4017 :: Output Channel Count [10506:24:1] - 622 - 09:49:54 Line 4018 :: Level Count [10506:24:1] - 268 - 09:49:54 Line 4019 :: String Size [10506:24:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4020 :: Command Size [10506:24:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4021 :: Output Channel Count [10506:25:1] - 622 - 09:49:54 Line 4022 :: Level Count [10506:25:1] - 268 - 09:49:54 Line 4023 :: String Size [10506:25:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4024 :: Command Size [10506:25:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4025 :: Output Channel Count [10506:26:1] - 622 - 09:49:54 Line 4026 :: Level Count [10506:26:1] - 268 - 09:49:54 Line 4027 :: String Size [10506:26:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4028 :: Command Size [10506:26:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4029 :: Output Channel Count [10506:27:1] - 622 - 09:49:54 Line 4030 :: Level Count [10506:27:1] - 268 - 09:49:54 Line 4031 :: String Size [10506:27:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4032 :: Command Size [10506:27:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4033 :: Output Channel Count [10506:28:1] - 622 - 09:49:54 Line 4034 :: Level Count [10506:28:1] - 268 - 09:49:54 Line 4035 :: String Size [10506:28:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4036 :: Command Size [10506:28:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4037 :: Output Channel Count [10506:29:1] - 622 - 09:49:54 Line 4038 :: Level Count [10506:29:1] - 268 - 09:49:54 Line 4039 :: String Size [10506:29:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4040 :: Command Size [10506:29:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4041 :: Output Channel Count [10506:30:1] - 622 - 09:49:54 Line 4042 :: Level Count [10506:30:1] - 268 - 09:49:54 Line 4043 :: String Size [10506:30:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4044 :: Command Size [10506:30:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4045 :: Output Channel Count [10506:31:1] - 622 - 09:49:54 Line 4046 :: Level Count [10506:31:1] - 268 - 09:49:54 Line 4047 :: String Size [10506:31:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4048 :: Command Size [10506:31:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4049 :: Output Channel Count [10506:32:1] - 622 - 09:49:54 Line 4050 :: Level Count [10506:32:1] - 268 - 09:49:54 Line 4051 :: String Size [10506:32:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4052 :: Command Size [10506:32:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4053 :: Output Channel Count [10506:33:1] - 622 - 09:49:54 Line 4054 :: Level Count [10506:33:1] - 268 - 09:49:54 Line 4055 :: String Size [10506:33:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4056 :: Command Size [10506:33:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4057 :: Output Channel Count [10506:34:1] - 622 - 09:49:54 Line 4058 :: Level Count [10506:34:1] - 268 - 09:49:54 Line 4059 :: String Size [10506:34:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4060 :: Command Size [10506:34:1] 199 byte(s) Type: 8 bit - 09:49:54 Line 4061 :: Output Channel Count [10506:35:1] - 622 - 09:49:54
Does anybody see anything strange here that I'm missing? Any kind of hint would be *much* appreciated... I'm at a complete loss as to what's going on here. I've been 'updating' my panels to a new design that's quite a bit different, and somehow it seems to be related. If I leave the 'old' design on the MVP and let it boot up, 'Volatile Free' drops by about 1.1MB - not enough to bring the server down. The 'new' design must drop the RAM by more than that. I also tried to 'remove user pages' from the MVP and let it boot - and it only dropped the RAM by 35KB! Seems to be related to the panel file somehow. I have also been able to bring the system down with a CV-7 - so it's not specific to the MVP's (although I did do a 'save as' panel type from the MVP panel file). I've checked my online events and there's nothing I see that would eat up the RAM like that. Maybe the system can handle 12 panels 'as is', but the 13th is too much?
Thanks in advance for your comments and suggestions.
Regards,
Mark
0
Comments
Polk XM Radio (Port 14):
DATA_EVENT[dvTP_XM] { ONLINE: { SEND_COMMAND vdvXM,"'RADIOID?'" SEND_COMMAND vdvXM,"'SIGNAL_STRENGTH?'" SEND_COMMAND dvTP_XM,"'!T',nTextButtons[TXT_STATION]" SEND_COMMAND dvTP_XM,"'!T',nTextButtons[TXT_ARTIST]" SEND_COMMAND dvTP_XM,"'!T',nTextButtons[TXT_GENRE]" SEND_COMMAND dvTP_XM,"'!T',nTextButtons[TXT_RADIOID]" SEND_COMMAND dvTP_XM,"'!T',nTextButtons[TXT_SONG]" SEND_COMMAND dvTP_XM,"'!T',nTextButtons[TXT_CHANNEL]" } }Here's another (Port 10):
DATA_EVENT[dvTP_UTILITY] { ONLINE: { STACK_VAR INTEGER i i = GET_LAST(dvTP_UTILITY) // Turn page tracking on SEND_COMMAND dvTP_UTILITY[i], 'TPAGEON' SEND_COMMAND dvTP_UTILITY[i], "'!T',5,'SYSTEM MESSAGE'" SEND_COMMAND dvTP_UTILITY[i], "'!T',6,' ',DAY,' ',DATE,' ',TIME" SEND_COMMAND dvTP_UTILITY[i], "'!T',7,' '" SEND_COMMAND dvTP_UTILITY[i], "'!T',8,'Device ',sPANEL_INFO[i].DESCRIPTION,' is online '" SEND_COMMAND dvTP_UTILITY[i], "'!T',9,' '" SEND_COMMAND dvTP_UTILITY[i], "'PPON-DialogBox_Centered'" SEND_COMMAND dvTP_UTILITY[i], ("'CLOCK ',DATE,' ',TIME") SEND_STRING 0,"DATE, ' ', TIME, ' - Touch Panel ', sPANEL_INFO[i].DESCRIPTION, ' went online.'" } }I didn't notice anything here that would eat into my RAM, but I may have gotten glossy eyed looking at it for so long.
Thanks for your help!
Mark
More than likely, some port numbers were actually skipped and are not being used at all. However, resources are still allocated for them. Try it - define a panel as using port one, and port 10 on a master. Even though the panel has no references to ports 2-9, your online tree will show all ten ports. Memory and events are assigned to each one, whether you are using them or not.
I find it difficult to believe your panel design really needs 34 (or more) ports. Consolidate them and get rid of the in-between, unused port numbers. If it really does need that many ports, you may need to think of another way to do it - like sharing ports for some devices, and using a virtual with dynamic combines. But you got to get rid of all those ports when you have so many panels.
I'm thinking the problem is something to do with this, similar to what DHawthorne said about ports but with levels. If you have levels it sets up stuff for all the intermediate levels. Plus I forget off the top of my head but it seems like those are over the max number of levels you can have. I'm guessing 256 is the max. If you're constantly updating a level, it probably doesn't know what the existing level is so it keep sending data out to that level on the tp all the time.
Also noticed you're sending a text string out to the panel with the date and time. You can use the panels system ports as that will sync up with the master's time automatically. Unless you're doing something like someone else did where the user can change the timezone of the panel to match his different branch offices.
Also I noticed you were sending o
You're the man! You were right - I do have quite a few ports defined both in my code and on the panels. My code definitions basically look like this:
// TP11 - FAMILY ROOM (MVP-8400) arqTP11 = 10506:1:1 // AudioReQuest vrqTP11 = 10506:2:1 // VideoReQuest hvacTP11 = 10506:3:1 // Heating adaTP11 = 10506:4:1 // ADA Suite 16 azcTP11 = 10506:5:1 // Audio Zone Control avTP11 = 10506:6:1 // Audio/Video Equipment radTP11 = 10506:7:1 // Radionics Security scTP11 = 10506:8:1 // Security Cameras kalTP11 = 10506:9:1 // Kalatel Security Camera DVR utilTP11 = 10506:10:1 // Utility/Touchpanel Routines atvTP11 = 10506:11:1 // Apple TV dtvTP11 = 10506:12:1 // For Rack DVR (HR20-700) xmTP11 = 10506:14:1 // Polk Audio XRt12 xmdTP11 = 10506:15:1 // Polk Audio XRt12 - Direct Channel Input dvdTP11 = 10506:16:1 vzcTP11 = 10506:17:1 // Video Zone Control weatherTP11 = 10506:23:1 // RSS Weather Feed c1TP11 = 10506:26:1 // Parasound C1 (Home Theater) c2TP11 = 10506:28:1 // Parasound C2 (Living Room) hkTP11 = 10506:29:1 // Harman Kardon DPR-1001 apTP11 = 10506:30:1 // AutoPatch 1YDM Component Video & Digital Audio Switch tv1TP11 = 10506:32:1 // Samsung DLP TV in Living Room tv2TP11 = 10506:34:1 // Samsung DLP TV in Family Room tv3TP11 = 10506:36:1 // Samsung DLP TV in Exercise Room tv4TP11 = 10506:38:1 // Samsung DLP TV in Downstairs OfficeOn the panel side, I incorporated the nicely done weather module that was posted on the board (VAV!) and it had a reference to port 1 on the panel file that was used for sunrise and sunset. Since I knew I used port 1 for the AudioReQuest, I 'temporarily' set it to 100 - thinking I would set it to a port number out of the way for now and circle back to it later. Unfortunately, by setting it to 100 it was allocating memory for ports 1-100 as you described. My controller could handle six panels with 100 ports, but the seventh would cause the out of memory error. Thank you very much for your help! I am now back up to 21.8MB available 'Volatile Free' instead of just 1.6MB!
While we're on the subject of maximizing memory usage and minimizing port usage, I thought I might as a couple more questions. Does the controller allocate the memory based on definitions in code, or by the maximum port number that is defined in the actual TP4 file? Based on my experience it seems to be the latter, but I thought I would just check. Is there any way to control the 'output channel count' or the 'level count' that's displayed in the notifications log? As far as consolidating ports goes, I could roll up my four TV's (for example) into one port and have channel codes 1-70 reference IR codes for TV1, 71-140 reference TV2, etc. If I remember right, there's a limit on the array size too - isn't there? Any suggestions on how to best consolidate ports, or to maximize the number of channel codes per port?
As far as having a need for 34 ports, I probably need more like 24 or so (at the moment). I'm trying to make all of my panel files identical, based on panel type (CV-7, MVP-8400, CV-15 & CV-17). In code, I check to see what panel is requesting a certain menu, etc. and then redirect it appropriately. It's alot easier to modify one panel file for all CV-7's than to have a panel file for each location. I've also setup my system to allow users to 'select' any audio or video zone and to control everything there - hence the need to control basically everything from each panel.
You were right about my having unused in-between ports - I was trying to leave a little space between them so I could logically expand (and insert as necessary) in the future. I had no idea it was eating up so much RAM. I'll focus on consolidating ports and being a little careful about expanding my usage of them in the future.
Thank You!
Mark
In my office system I'm quite happily running 30 ports but only on 2 full time TPs.
I now remember Dave mentioning this before. I think there was a thread about it to be honest, but I'm not entirely sure. Regardless, let us know how you fair on the rest of the job.
Thanks for your comment. I believe those levels in the notifications are accurate - the port numbers noted match with what I'm using. Maybe I should use something below 256, but it seems to work OK. I put in a global variable (via a structure) that keeps track of whether or not the level is in the process of being changed, and then set it back to 'no' after a wait. I know what you're talking about regarding the constant updating of levels, but this seems to work. I don't know why it shows the various types supported, or how that can be controlled. You're right about the date and time - I should probably use the panel's system ports instead.
Thanks for your help!
Mark
But those are virtual interfaces, not panel ports, no? It's not so bad if they only appear once and aren't being multiplied by every panel. I can't imagine an automated system where you would want to do the switching on a panel; it should all be behind the scenes when you select a source.
Nope! This is the new Duet Module: When I first looked at the module as a usable option I looked at this and was completely dumb founded. It appears they couldn't figure out how to re-use numbers 1-10 so they just made a different port instead.
I don't believe this was written by an AMX staffer but some one from AP.
Regarding the conservation of ports, is there any limit to the number of command codes that can be used on one port? Is there a maximum command code? Do you generally have different arrays for each IR device, or do you have one large array that lumps them all together? The way I see it, you can either lump them together and do a SWITCH...CASE or you can have multiple button events referencing the different arrays (which references each IR device separately) - right? Which do you prefer?
Thanks again for your help.
Mark
Do not be pernoid be the use of many ports. Alot of programmers use a single TP port for single device control. So you can have up to 100 ports in use by a TP. I would suggest you comment out your code until you find out what is causing the lock up. I would start by commenting out all your online events for your TPs. You may also want to do a debounce on your online events, if you have a lot of panels that come on at the same time you code could execute tons of time. I would suggest a 2 second debounce time, with a cancel wait right before
the wait 20.
As far as your question about qty of send commands to a netlinx device. The G4 touch panels pretty much can take the commands as fast as possible. But if I am sending alot of them I tend to queue them and pace them to the TP. Keep in mind that all programmers need to learn to manager resources and processing time on any platform. That is the main differance between an ok programmer and a great programmer.
DATA_EVENT[dvTPArray] { ONLINE: { CANCEL_WAIT 'TP COMING ONLINE' WAIT 20 'TP COMING ONLINE' { // DO INIT STUFF NOW. } } }Jeff, he already confirmed it was the number of ports. It matters a lot on big systems with a lot of panels; I know this from bitter experience.
It's going to vary with the size of the rest of your code. In many cases, you can probably get away with it. IN some you are not.
I guess they don't cover this in all the training courses, because when I went, the instructor was very adamant about it: don't skip port numbers because of the resource drain. It's a real issue, and it doesn't rear it's head under all circumstances, but that doesn't make it any less there.