|
|
This topic comprises 2 pages: 1 2
|
|
Author
|
Topic: Out of Virtual Memory
|
|
|
|
|
|
|
|
|
|
|
|
|
Tony Bandiera Jr
Film God
Posts: 3067
From: Moreland Idaho
Registered: Apr 2004
|
posted 12-15-2015 12:35 PM
quote: Randy Stankey
We've also noticed that automation cues aren't working properly, either.
Projector cues like lamp, input switch and dowser work okay but lights and sound cues don't work or, if they do, work erratically. We've been operating the lights and sound manually.
The lights and sound are operated through an AMX control system.
Since these things from the AMX aren't working, I wonder if the problem is coming from there.
Is is possible that a malfunctining AMX could be sending bad codes/commands back to the projector or automation that would cause problems like we are seeing?
Yes the problem is likely coming from the AMX system.
Depending on how the code for the AMX system was written, it could have become corrupted or buggy and is sending multiple commands to the system and causing the projector to keep acknowledging them which can eat up the TPC memory.
(A simple test would be to disconnect the AMX system and run totally manually from the server and projector to see if the problem goes away. Does the AMX communicate to the projector thru a serial RS232 connection? If so, simply unplug the RS232 cable at the projector. If the AMX is thru ethernet, you must disconnect or power down the AMX system to test.)
A cold reboot of the AMX would probably help...BUT make sure you have the AMX program code handy (and the software and know-how to reload it) because if you do a cold reboot and the master card/processor battery is dead (possible if it is more than 5 years old) you will end up with a brick. Luckily, unlike the TI board, you can simply reload the system program and recover.
If your AMX is the older Axcess platform I have extensive experience in programming them, so if you do have a copy of the program code you can email it to me and I can look it over for bugs. I can also review the newer Netlinx format, but have less experience with it.
One issue I had with a number of screening rooms I dealt with in the past with the Axcess systems was a previous programmer would have redundant or unused device code left in the mainline program which would cause random system crashes or erratic behavior. Deleting that code or changing it to a system call format cleared up the issues.
| IP: Logged
|
|
|
|
Tony Bandiera Jr
Film God
Posts: 3067
From: Moreland Idaho
Registered: Apr 2004
|
posted 12-15-2015 10:18 PM
Ahh, the NI-3000 .....good unit.
Pulling the power cord and leaving it off for at least 20 seconds is the only way, unless you have a computer with the Netlinx Studio software (and know how to use it), the NS software has a system reboot option. (Technically that would be a warm reboot but that still often clears up some issues.)
Make sure that all of your connected systems are powered off during the reboot (masking motors, projectors, servers..dimmers would be ok to leave on) as AMX systems will often fire off random relays and commands during the final stages of the reboot process...(this is actually the master doing a self-test of all relays and ports) ....anything like masking motors (or film changeover dowsers) that should not ever see conflicting actions could be damaged..(usually such conflicts are only a second or two long, not really damaging but can scare the crap out of you.) Also note that any buttons or touchpanels that "light up" or otherwise provide feedback of what a device is set to will not reflect the ACTUAL status after a reboot. That corrects itself when said buttons/commands are executed.
A brief AMX tutorial: The older Axcess systems' program code runs in a "closed loop" style, where the program's "mainline" runs constantly from start to finish and repeats endlessly. As it runs, the mainline program is looking for inputs (commands) or "feedback" (usually levels or positional information) as it runs, and makes changes accordingly.
It is this constant looping action that can, with poorly written or redundant code, cause problems as actions are repeated or altered despite the system not being commanded to do so. A lot of that is avoided by using the "system calls" in the program... (I'll give an example of a call following.) basically a system call is a series of code written that does NOT run in mainline UNTIL the mainline command for that call is activated. (It can also be loosely, but not technically, be considered a "macro".)
An good example was the code I wrote for UC Irvine's screening room.. a call was written for an "Auto Show Start" which did all of the following in order: - Start Ipod for intro music
- After a time delay, set house lights down to "entr'e act"
- Start the projector motor
- open the screen curtain
- set masking to selected format
- start houselights to full dim
- open changeover dowser
- set cinema processor to format 10
If all of that code was in mainline, it could slow the response time of the system down, or create potential bugs or miscues if a valid command that was time-critical (think serial or other data strings to projector or server) was supposed to be executing while the program was reading that code. (Plus it makes making any changes to the system call code a lot easier and faster...I went thru several iterations of it to get the events timed to perfection.)
Netlinx was designed to eliminate some of the above mentioned issues, as it basically has a very streamlined "mainline" that it runs, all functions became very much like the system call protocol..it executes commands faster and more reliably.
It also eliminated the special 4-wire AXlink bus, replacing it with CAT 5. Easier and cheaper to run. (You will still see an Axlink 4-position Phoenix connector on virtually all Netlinx masters to allow some backwards compatibility.)
| IP: Logged
|
|
Randy Stankey
Film God
Posts: 6539
From: Erie, Pennsylvania
Registered: Jun 99
|
posted 12-18-2015 02:16 PM
I'm starting to think that the problem lies in the AMX system, rather than the projector or TPC.
I pulled the power to the AMX and rebooted it but it seemed to cause more trouble than it solved. The fire alarm relay goes through AMX. When the thing rebooted, the fire alarm interlock tripped on the projector. It wouldn't run unless the fire alarm wires were disconnected and jumpered. The exhaust fan damper isn't working right, either. I'm guessing that the damper is also controlled by the AMX.
I gather, from what y'all are telling me, that the AMX has gone haywire. It is sending spurious messages back through the network, to the projector, and the projector's memory is filling up too fast because it has to respond to a million junk messages. Then, when we increased the amount of virtual memory for Windows on the TPC, it only masked the real problem. The AMX is still buggy and is still causing problems but they don't show up as often, except in the light, sound and environmental controls that are tied in though the AMX.
Sound reasonable?
Is there any way to go through the projector or the AMX log files to verify this?
| IP: Logged
|
|
Tony Bandiera Jr
Film God
Posts: 3067
From: Moreland Idaho
Registered: Apr 2004
|
posted 12-21-2015 12:57 PM
The projector might have log files in regards to network activity, but I haven't had the need to access them so Christie Digital would be the ones to ask.
The AMX system does not keep log files. There is, in the Netlinx Studio software (program for PC to write, edit and load code into AMX hardware) a so-called "debugger" that works about 10% of the time. (The code compiler does a better job of finding and pointing out code issues, but it only looks at syntax and logic, it can't find things like an error where your lights command actually flushes the toilet.)
Randy, try this to run your shows:
Disconnect the AMX system from the server AND projector ONLY. Use the server's TMS to run your shows. That will isolate the fault to either the AMX (most likely) or your projector/server.
You don't even have to run a full show if time is limited, just run various trailer packs or parts of shows to see if the projector and server are getting along.
As for the fire alarm trip and damper, as I said before during a reboot the AMX will test fire all relays and ports, and it will lose ALL track of system status and feedbacks. Basically ALL buttons have to be pressed and the devices that talk back to the AMX will have to send their status back to the AMX before the system will return to normal.
That said, you need an AMX certified programmer to come check the system, retrieve and reload the software to the AMX controller and fix any bugs. Without the Netlinx Studio software and experience it is not a do-it-yourself job.
| IP: Logged
|
|
|
|
All times are Central (GMT -6:00)
|
This topic comprises 2 pages: 1 2
|
Powered by Infopop Corporation
UBB.classicTM
6.3.1.2
The Film-Tech Forums are designed for various members related to the cinema industry to express their opinions, viewpoints and testimonials on various products, services and events based upon speculation, personal knowledge and factual information through use, therefore all views represented here allow no liability upon the publishers of this web site and the owners of said views assume no liability for any ill will resulting from these postings. The posts made here are for educational as well as entertainment purposes and as such anyone viewing this portion of the website must accept these views as statements of the author of that opinion
and agrees to release the authors from any and all liability.
|
Home
![[Wink]](wink.gif)
Printer-friendly view of this topic