Home AMX User Forum AMXForums Archive Threads AMX Hardware MAX by AMX

"Max Queue Count" from Max Module

Okay, I have a pretty big system (14 panels, 15 modules including a Max system). All was well until I added a small module for a Polk XRT12. The timeline wasn't firing and the buffer was always empty.

Turns out running by itself it is fine, running in the system it blows up. During bootup I notice the Max Queue Count "error" is getting all the way to 500, which can't be good. I disabled the Max module (UI module being called 14 times) and everything is fine and the timelines are running again.

Anyone know if the issue is the Max module or if it is more likely something else and the Max just puts it over the edge?

Comments

  • ericmedleyericmedley Posts: 4,177
    Sounds like the two modules are using similar device numbers and getting confused. You might load each module separately and see what devices they are creating.
  • DHawthorneDHawthorne Posts: 4,584
    The MAX is just putting it over the edge. DMS keypads tend to do the same thing. It's not a fatal error with "pending" messages ... even a working system might get that from time to time when things get busy. It's when the queue is suspended outright that you are in trouble.

    Is the Queue_and_Threshold_Sizes.axi include part of your project? That may fix you up if it's not.
  • It is included - I am going over 500 and getting the error. Do I do anything with the include or just have it there? I got it down to 300 whilebooting, but added another module (that uses 14 UI modules) and it is over the edge again. My header and footer are disappearing at random now as well, I need to figure this out :(

    Curt
  • Is it normal to see this number go up some while rebooting? On a larger system, does everyone see this number climb at least a bit? I am just trying to figure out what my goal should be, nothing, or just a number less than 500.

    I still have about 8 more modules to add, which seems impossible right now!

    Another thing, this is a three master system, but the other two masters have no code on them, basically just being used to give more ports.

    Curt

    (and sorry this thread is under Max, since it seems it has nothing to do with that!)
  • Yeah, not MAX I think.

    If you have coded in a non-AMX manner, you will have made many assumptions about what is lightweight and what is heavyweight, and you may be mistaken. I've been there!

    The first thing to try is to pace the startups of your modules. Give each module a number and run its startup delayed by maybe nModuleNumber x .5 second.
  • So what is it that is getting it clogged up, the modules themselves, or just code ONLINE or DEFINE_START ?

    And sheesh, I wait long enough for it to boot already :)

    Curt
  • Uh oh, so, I have a lot of data going on, not in modules, but mainline - initializing all of my rooms in code like this:
    kitchenLightingButtons[1].buttonName = 'Vol+'
    kitchenLightingButtons[1].buttonType = BUTTON_TYPE_VOL_UP
    kitchenLightingButtons[1].buttonID = 1673
    kitchenLightingButtons[2].buttonName = 'Vol-'
    kitchenLightingButtons[2].buttonType = BUTTON_TYPE_VOL_DN
    kitchenLightingButtons[2].buttonID = 1674
    kitchenLightingButtons[3].buttonName = 'Source'
    kitchenLightingButtons[3].buttonType = BUTTON_TYPE_SOURCE
    kitchenLightingButtons[3].buttonID = 1672
    kitchenLightingButtons[4].buttonName = 'Power'
    kitchenLightingButtons[4].buttonType = BUTTON_TYPE_POWER
    kitchenLightingButtons[4].buttonID = 1671
    kitchenLightingButtons[5].buttonName = 'Garbage Disposal'
    kitchenLightingButtons[5].buttonType = BUTTON_TYPE_LIGHT
    kitchenLightingButtons[5].buttonID = 1560
    kitchenLightingButtons[6].buttonName = 'Lights'
    kitchenLightingButtons[6].buttonType = BUTTON_TYPE_LIGHT
    kitchenLightingButtons[6].buttonID = 1546
    
    kitchenLightingLoads[1].loadName = 'Island Pendants'
    kitchenLightingLoads[1].loadID = 443
    
    kitchenSecurityZones[1].zoneID = 333
    kitchenSecurityZones[1].zoneName = 'Glass Break'
    kitchenSecurityZones[2].zoneID = 334
    kitchenSecurityZones[2].zoneName = 'Kitchen Motion'
    
    kitchenSources[1] = SOURCE_REQUEST1
    kitchenSources[2] = SOURCE_REQUEST2
    kitchenSources[3] = SOURCE_HDRADIO1
    kitchenSources[4] = SOURCE_XMRADIO
    
    Kitchen.currentAudioSource = SOURCE_HDRADIO1
    Kitchen.audioType = 1
    Kitchen.zoneName = 'Kitchen'
    Kitchen.audioPower = 0
    Kitchen.hvacZone = HVAC_ZONE_MAIN_1
    Kitchen.audioSwitcherOutput = 25
    Kitchen.videoZone = 1
    Kitchen.security = kitchenSecurityZones
    Kitchen.buttons = kitchenLightingButtons
    Kitchen.loads = kitchenLightingLoads
    Kitchen.sources = kitchenSources
    Kitchen.zoneID = 6
    Kitchen.totalSources=4
    

    Imagine that times 30 rooms - this is in the on-start. Is this a bad idea? I liked the readability of assigning it all there, but not at the expense of explosions in the code...
  • DHawthorneDHawthorne Posts: 4,584
    Generally speaking, data assignments are not an issue; it's initializations that require sending commands out to a device that bog things down. I have a very large system that is running over a dozen MAX UI modules, and it will climb up to about 150 or so in the queue count, and even appearing to freeze at a few points in startup, but then it catches up in a big burst and all is well.

    At one point, I had a serial to IP converter on the system, and that thing was enough to blow up the system. Too much processor attention was needed while it was connecting ... and it took me forever to realize that was the problem, since it generated no errors whatsoever, just took a long time.
  • You mentioned that you have 3 masters, where only one is running code ?
    If this is true, I would suggest to put all the parsing stuff for your serial ports to the masters where the physical devices are connected.
    If you place the code all into one master, every byte from every serial port has to be transmitted over the master2master connection to ONE master and must be processed.
    I think if you have 3 ni3100 (21 serial ports), this would give a high load.

    If you have modules for the devices, place the com modules into the masters your serial devices are connected to and only share the virtual devices amok the masters.

    Also isn't it possible to connect some of your panels to different masters and do all the processing there ? This would also give a better reliability to your over all system. If one master stops working, still a part could be controlled,

    For example: you could connect 10 panels to one master and place all the UI stuff to this master. This way you will benefit from all the cpu power of all masters.

    Hope this helps.
    Jurgen
  • Thanks everyone for the help on this! I have everything written in modules, so moved the COMM code to the three different boxes, I also divided up the nine IP devices as well. It still hits 300 on the booting machine, I have a sneaking feeling it is my autopatch modules (controlling two autopatch boxes). At least it is bootable and I can tweak from there!

    Curt
  • DHawthorneDHawthorne Posts: 4,584
    TrikinCurt wrote:
    Thanks everyone for the help on this! I have everything written in modules, so moved the COMM code to the three different boxes, I also divided up the nine IP devices as well. It still hits 300 on the booting machine, I have a sneaking feeling it is my autopatch modules (controlling two autopatch boxes). At least it is bootable and I can tweak from there!

    Curt
    The comm module should only be on ONE master. It's the UI modules you need to spread out.
  • Dave,

    Curious on why? I am not doubting you, I just don't have a clue and want to understand! Jurgen mentioned moving the COMM modules to the box that the device was connected to, which seemed to make sense.

    At this point I have COMM and UI split amongst the boxes, which seems to be giving me my best performance yet, at least at boot up.

    Curt
  • ericmedleyericmedley Posts: 4,177
    TrikinCurt wrote:
    Dave,

    Curious on why? I am not doubting you, I just don't have a clue and want to understand! Jurgen mentioned moving the COMM modules to the box that the device was connected to, which seemed to make sense.

    At this point I have COMM and UI split amongst the boxes, which seems to be giving me my best performance yet, at least at boot up.

    Curt

    Well, one reason that comes to mind is that the multiple COMM modules are maintaining multiple IP connections on the MAX server. That's a lot of work for the MAX to do. The MAX is not the quickest ship at sea for that kind of stuff. You can maintain a lot more control of network traffic if you do it from the single netlinx master.

    I have some very large systems with multiple touch panels and multiple AVMs that run from a single master just fine. In fact, I've never had to break up the processing and have kept all the program in one master. I do use multiple masters as local control boxes. But the program resides on one box.
  • DHawthorneDHawthorne Posts: 4,584
    TrikinCurt wrote:
    Dave,

    Curious on why? I am not doubting you, I just don't have a clue and want to understand! Jurgen mentioned moving the COMM modules to the box that the device was connected to, which seemed to make sense.

    At this point I have COMM and UI split amongst the boxes, which seems to be giving me my best performance yet, at least at boot up.

    Curt

    Because you now have multiple NetLinx masters controlling the same device, and every time one does something, the others are going to have to process the feedback. There is also the possibility of one telling the MAX to do something that conflicts with what another is telling the MAX to do. The MAX, as noted, will only connect to one at a time ... this is a huge bottleneck and is bound to cause issues.
  • Not that this is a solution, but there was a separate discussion about modules vs Include files. I have found that running the same code in an Include file as opposed to modules eliminates at least some of these issues. I can't explain why, but I have found that some modules just won't run with others. I have also found that if you change the order of the modules, then the code will run just fine. And it always isn't just a start up issue.

    With an include file, I always know what to expect. With modules, sometimes it is just a cr_pshoot as to how two modules will react with each other.

    Hope this helps. Just my two cents.

    Sheldon Samuels
  • Joe HebertJoe Hebert Posts: 2,159
    ipssheldon wrote:
    I can't explain why, but I have found that some modules just won't run with others. I have also found that if you change the order of the modules, then the code will run just fine.
    Two points of advice that I've been given in the past:

    1) Modules belong at the end of STARTUP.

    2) All like modules need to be grouped together.
  • There a pro and cons of modules. Also there are pro and cons for include files.
    For both solutions you have to pay attention that you do not use two instance for the same physical device to control. This will always cause trouble !

    Specially to max you should only use one comm module that talks to max at all. In seldom cases you can use two comm modules that talk to the max server so you get a better reliability of your system.

    To include files: I use them when I have a "one time" solution. Also the benefit is, that you do not have the overhead of the events to get the information to and from the module. I guess this is why include files perform better.

    [off topic]
    But when ever I have a chance I prefer to make module files. I have a good template I always use as a start where I have a send queue and the preliminary parsing of commands and device feedback. Also I do not have to take care about variable names if the already exist in the main program.
    But the best benefit is, that if I have more than one instance of a device, simply include a second instance. Also this does not blow up the code since (remember: multiple instances of a module only add the "runtime" overhead to your program). Also maintain the code is much easier. If I make a fix in the module, ALL places where it is use benefit from the fix. This is not the case for include files, at least not every time.
    [/off topic]

    But it is very important to place the COMM modules in the master where the physical device is connected and only share the virtual device between masters.
    In case of max you should only use on instance of the comm module at all as mentioned above. If I am not mistaken, the problem comes up if you have more than 3 connections at a time (COMM module, WinMAX, MAX-MDL200).
    Regarding to MAX this is my personal experience.
Sign In or Register to comment.