Define_modue issues

John Paul

Now I have an AMX controller with 12 touch panels connected to it. Each touch panel is having its own connection to the Autonomics MCS server and the media gets uploaded to the touch panel. Each MCS has four zones for control. Now we have added another Autonomics MCS with a different IP with 2 zones. So there will be simultaneous 24 connections with 12 to one ip and another 12 to another ip.But when i add this to the AMX code, the controller is not able to load the virtual devices and is not able to function. I have attached the source code file for this room. There are other rooms which have lesser number of touch panels connected to a master and those are functioning well. Please guide me in resolving this issue.

I have attached the codes for the controller here and also the default autonomic code available from http://www.autonomichome.com/support.htm . I am using the include file 'incHT_MediaServer.axi' to connect to the first Autonomics MCS on ip (10.10.1.10) and the include file 'incKids_Autonomics.axi' is where i connect to the second Autonomics MSC. Now if i comment out the this part from any of the include files
DEFINE_MODULE 'Autonomic Controls WMC UI' MCEUI1 (vdvMCE, dvTPFLR1MS, cMCE_SERVER_IP,iMCE_ART_PORT)

or //DEFINE_MODULE 'Autonomic Controls WMC Comm' MCECOMM1 (vdvMCE, dvMCE, cMCE_SERVER_IP, iMCE_SERVER_PORT)

then the controller loads up all the virtual devices and the room starts functioning but when both UI modules are added then, the controller just wont load the virtual devices. Now i have added multiple COMM and UI modules since i want to control the Autonomics individually and the UI module has page flips in it, so there need to be seperate UI modules per touch panel.

Andrew G Welker

Do the modules have unique identifiers? Each module should have one. The correct format is

define_module 'some_module' id1(vdvdevice,dvdevice)
define_module 'some_module' id2(vdvdevice2,dvdevice2)

John Paul

Yes, the code i have attached shows that i have used unique ids for each module.

Jimweir192

Sounds like a memory issue.

if you telnet in as soon as your able to connect after a reboot and do MSG ON do you get any error messages?

John Paul

i get no error on telnet. I have attached both the telnet session and diagnostic session. Also the duet memory for this controller ni3100 sig is 12m

Ant

I'm getting the same issue.

I have 6 TPs connected to a NI4100.

Thus far it will only function with 2 modules instantiated.

Anything over that my non-volatile memory is exceeded.

I've tried replacing variables with volatile variables.

Does anyone have a solution for this?

It's a shame that the module does have a duet device

ericmedley

You might be at the stage that you need to write your own module. We did this since we could not implement their module with as many touch panels as we typically use. My module handles a large number of UIs and can control all zones of the Autonomics box on one comm module. It's way less of a memory hog. Personal note... Writing media server modules is probably my least favorite thing to do. They can be rather complex animals and have yet to see one where the company provides adequate documentation on their API. Also, you really need to fully load one up with media and subscriptions for true testing. Working with one out of the box will never give you a full real-world shakedown. Other than that it's great.

shr00m-dew

I'm running 15 of their comm modules and 15 of their UI modules on the only job we sold it on. There's a reason it's the only job we sold it on. The modules have been modified (and re-modified every-time they force a firmware upgrade).

Key's are:

COMM:

volatile char mceBuffer[16000] ~line 58

UI:
local_var volatile char val[10000]; ~line 1003
local_var volatile char datum[16000] ~line 2472


This is with version 2.4 of their module. I see they have a 4.5.4 now that require 4.5 firmware. I'm sure I'll be modifying that soon enough.

Kevin D.

Ant

Kevin D,

Are you saying by changing the chars arrays to volatile the system worked well? did the art work populate correctly?

Did you upgrade this system to the latest firmware? Was there any other findings you made that allowed the system to operate more smoothly?

Thanks

shr00m-dew

I'm saying changing those lines will let a lot of the modules runs without crashing the master. Looking at the TP's I killed all the cover art except for the now playing.

The player had to be sent off and completely rebuilt, which of course did require me to update to the 4.5.4 module. Luckily despite going from 2.4 to 4.5.4, nothing much changed. I was able to to a file compare and reapply my changes where needed.

In this instance, we do not allow changing of zone controlled from the user. When the panel comes online I've made the UI module for that TP poll the available zones, and then depending on the zone the user selects (from the AV menu), run a DO_PUSH for the appropriate zone.

Luckily this customer pretty much picks a Pandora or Sirius station and that's it. I'm sure if they used more of the streaming choices or itunes music I would have had to modify the code even more.

Kevin D.

Ant wrote: »

Kevin D,

Are you saying by changing the chars arrays to volatile the system worked well? did the art work populate correctly?

Did you upgrade this system to the latest firmware? Was there any other findings you made that allowed the system to operate more smoothly?

Thanks

Duncan Ellis

issue with module

Hi

I recently found out that variables in modules are no longer consider 'volatile' unless you specify them to be. I was told originally that all variables in modules were volatile and there was no kind of persistence. Apparently this changed a few months ago, according to tech support, because I got caught out with this. I had declared local variables but not made them volatile, when i ran multiple instances the processor just crashed - I only spotted this because I telnetted in and saw that I had negative volatile RAM left.
So it may be that the module are running needs recompiling by the author, declaring the bulk of the variables as VOLATILE, then it will probably run.

Interesting to see though that there was no notification of change of this status. You could argue that good programming practice says that you declare all of your variables as VOLATILE/NON-VOLATILE or whatever, but I would have said that a change like this should be seen as having impact and should be documented.

Anyway, I'm off my soapbox, hope this helps

Duncan

John Nagy

Duncan Ellis wrote: »

Apparently this changed a few months ago, according to tech support

How did the change occur? Did it happen when you changed to a new NI firmware, or the compiler? Such a change has to be somewhere, and it would pay to know where.

ericmedley

Wow!
If this is accurate information it is extremely troubling. Since modules are meant to be reusable and repeatable a programmer could conceivably now have a system that used to have several 10s of Mbytes of volatile RAM now trying to cram all that same previously working code into a significantly smaller block of non-volatile RAM.

I was in the habit of writing any data I needed to store in modules to disk as CSV or XML files. But now, even this can easily get blown up.

I question the wisdom of making this change especially since the default is not volatile.

As I check my modules, I'm glad to find that I did indeed declare them as volatile basically out of muscle memory.

vining

My recollection is variables have alway been non volatile if not explicitly specified as voltile or persistent. Default = non volatile.

ericmedley

vining wrote: »

My recollection is variables have alway been non volatile if not explicitly specified as voltile or persistent. Default = non volatile.

I remember it being default as volatile for a while back in the first days if Netlinx. It changed a few years in f I remember correctly. In fact I still find really old AMX written modules and UI code with the non-vol declared variables. I've always felt there should be no default. I feel you need to make your choices in the declaration.

vining

ericmedley wrote: »

I feel you need to make your choices in the declaration.

Agreed. I see very little use for non volatile so I've always explicitly declared 99.99% of them as volatile and my recollection still is that if I didn't declare anything it would be non volatile but being anal I would always declare it any way so it could be I've just been wrong all these years but since I always spell out what I wanted it's never been an issue.

Duncan Ellis

John Nagy wrote: »

How did the change occur? Did it happen when you changed to a new NI firmware, or the compiler? Such a change has to be somewhere, and it would pay to know where.

I don't exactly know when this occurred, but I had the same issue last week. I was working out in the the USA and I had to double up one of my module files and the NI just stopped working. When I looked, I was over capacity on non-volatile memory. I then defined everything required as VOLATILE and the problem went away.
I asked UK tech support and they confirmed that this is the case - see email snippet below:

"Good morning Duncan,

You are indeed right they have now by default set those variables to Non Volatile. We have come across this recently with a couple of other programmers. So they do indeed need to be assigned as volatile now. This was indeed a while ago 6 months approx. However there is no documentation that I have noticed or content in the readme.

So just to confirm you do have to define your variables as volatile now.

With regards to the 20” panel question I will see what I can find out for you"

...........go figure!

ericmedley

I just did a little experimentation with some of the AMX comm modules and I'm pretty sure there a some where they obviously didn't specify volatile or non in the declarations. I noticed the non-vol RAM useage going up with no other variables being declared.

Not that I'm in control, but it seems to me that it wouldn't take a ton of time or resources to put a few people on a project to go through all the modules written by AMX and correct this and repost new versions of the modules.

I'd do it myself, but.. well... you know...
e

ericmedley

ericmedley wrote: »

I just did a little experimentation with some of the AMX comm modules and I'm pretty sure there a some where they obviously didn't specify volatile or non in the declarations. I noticed the non-vol RAM useage going up with no other variables being declared.

Not that I'm in control, but it seems to me that it wouldn't take a ton of time or resources to put a few people on a project to go through all the modules written by AMX and correct this and repost new versions of the modules.

I'd do it myself, but.. well... you know...
e

Actually, as a VIP I would be happy to take on this project now that I think about it.