Axlink Buffer's responsibilities.
shr00m-dew
Posts: 394
in AMX Hardware
Got a question on what falls into the Axlink buffer. Got a job with a NI3100 that will seems to lock up after two days or so.
Symptom is none of the hard ports work, Axlink buffer is full at 800. Only error is like "Error sending message, retry 0" It counts 0,1,2 several times and then flushes the buffer. Rebooting is the only solution.
All IP based communication works fine through this. The only thing on Axlink is an Anterius RFID reader on about 200 feet of true Axlink cable. I removed the code for the RFID, still locks up. I've now moved the reader to the rack on about 6 inches of axlink cable and waiting to see if it still locks up.
The main reason I'm wondering if anything else can fill the axlink buffer up is because more often then not the cable boxes will need to be power cycled after it locks up. They are just ran IR off the master. I'm curious if bad IR or commands to the IR ports can lock the master up, which then keep sending out invalid IR data that lock the cable boxes up????
Kevin D.
Symptom is none of the hard ports work, Axlink buffer is full at 800. Only error is like "Error sending message, retry 0" It counts 0,1,2 several times and then flushes the buffer. Rebooting is the only solution.
All IP based communication works fine through this. The only thing on Axlink is an Anterius RFID reader on about 200 feet of true Axlink cable. I removed the code for the RFID, still locks up. I've now moved the reader to the rack on about 6 inches of axlink cable and waiting to see if it still locks up.
The main reason I'm wondering if anything else can fill the axlink buffer up is because more often then not the cable boxes will need to be power cycled after it locks up. They are just ran IR off the master. I'm curious if bad IR or commands to the IR ports can lock the master up, which then keep sending out invalid IR data that lock the cable boxes up????
Kevin D.
0
Comments
I usually had to go through the AxLink device change and painstakingly isolate each device until I found the culprit.
I feel your pain...
Of course it's crazy that this is the first job where we've actually used real shielded axlink cable..
Kevin D.
Ha! That'll teach ya!. If you'd just used an old lamp cord and a pair of jumper cables duct taped together we'd not be having this conversation.
It's funny.. because it's true :P
Wich Device number are you assigning to the Axlink device?
Does the controller still locks up if you completely disconnect the Axlink cable from the controller?
Or is there someo other type of power drop, 200 feet is not a long distance but maybe there is enough voltage drop. That could be casuing some problems
Actually, 200 feet is quite a distance. Depending upon the wire guage, the voltage drop can be several volts. Check you voltage at the far end with the device plugged in and see what you have. It might be pretty low.
My understanding has been that the drain should not be connected at both ends, as it can cause a ground loop. Or is that what you are saying, make sure it isn't?
Yup - I don't know if it really is a ground loop, as the ground connection is connected at both ends, and if it was going to loop that would do it. But my fealing is that you should only drain the shield back to earth at one end.
Unless you are an AES audio guy - they have started landing shield at both ends again...
I'm and AES audio guy and I do NOT land my shields at both ends!
Of course, most these young audio engineers probably don't know what an analog signal is anyway. I just did a session with an audio engineer who didn't know how to mic a drum set. That was discouraging...
RFID is set to device 128, not other axlink devices.
No drain connected on either end. If no lockups after running for 72 hours, I'll move it back on the wire and hook up the drain to the AMX side. Will test end voltage at that time as well.
Thanks,
Kevin D.
I honestly don't think it's the axlink device either. That's why I was curious what else could cause this.
[quoe]
In fact, some only have one serial device connected. The one common denominator to all of this <i>appears</i> to be polling rate of devices (ex. polling serial port for data every 150ms). When the polling rate is slowed down the problem <i>appears</i> to go away. Are you using heavy polling?[/QUOTE]
This 3100 is talking to a vantage system tracking 100 keypads and 180 loads, an Ademco Vista128, and 4 Kaleidescape players via IP. The other RS232 ports are tied to a RTI controller with only 232 in when someone is using a remote.
Vantage and Ademco are using modified modules from AMX, but nothing to effect polling. They send a ping transmission about once a second.
The Vantage could possibly be killing if it someone were to do a few all on/all off commands, but I'm running the same module on a much larger Vantage system with no problems (and that's a one master system with a lot of other stuff). We do have significantly more touchpanels on this job (12), and a all on/all off command would result in a maximum of 360 send_levels being sent to 12 touchpanels.
I'll probably go ahead and change it so that it only does a send_level loop when someone goes to the lighting control page. On that note, if I do a combine_device with a virtual, will the master automatically update the newly combined device?
But I can sit here and do a ton of all on's/all off's and not make it lock up, something they would never do.
Kevin D.
I have the same problem. Controllers are NI-700, NI-2100, NI-3100. Problem looks like at one moment AxLink queue starts to grow and all hardware ports stopped to work. But... there is no one (!!!) AxLink device connected to the controllers. Connected only RS-485 ports. Time to halt of controllers are different - from 2 hours up to 30 days. But result of halting is 100%.
The problem starts after changing of firmware for master and NI-device to 3.50.430 and 1.20.7. Before this all work well except of some problems that were resolved by new firmwares.
Before your message I think that the problem happens only with my devices controlled by AMX. But now I think that problem is with new firmwares.
Can you send to me protocol for your RS controlled devices? And type of control - RS232 or RS485?
Much of the audio world would connect the ground wire to the chassis of the devices at both ends. This is to deal with devices with "Pin 1 Problems" where there is a long and/or less than ideal path inside the device from signal to chassis ground.
I personally beleive that ground lifting is a fix, not an initial system design.
I let the system roll with the new changes for a week. Added the RFID reader back at the end of the line and let it roll for another two weeks. No lockup's in that period.
Kevin D.
If you must refresh a bunch of levels at an ONLINE, it's best to create a queue or timeline mechanism to throttle them back a bit.