NI 2100 no programm run

thomas.jud

I've a big problem with a big AMX System with about 30 Panels, 4 Master NI2100, 2 Frames and any I/O Interfaces.

Problem:
intermittently the programm standing still. No action on all ports and panels.
intermittently means one time in 1 to 3 Weeks

What i see:
- All devices in the Online Tree
- Telnet is available
- Status LED blinking
- A very high CPU usage (up to 99%)

What i not see:
- no action on Notification
- no action on Diagnostics
- no Input LED

What i did:
- A very large programm runs (historicaly) just on one Master.
- Firmware Upgrade Master to 3.60.453
- Firmware Upgrade Device to 1.30.8

Can anyone help me ?
I think the cpu usage is too high.. or should i upgrade the firmware to 4.1.363 ?
Thanks

jjames

From what I understand, 4.x firmware has been around for at least a year and a half, however AMX has yet to release it for download (publicly). This speaks volumes, IMO.

That being said, I don't believe you need to upgrade the firmware to fix, in my opinion, is most likely a code problem. Here's what I would do: put in a button monitoring system. Create a [dv_panels,0] button even so it captures all button presses (do this for each port for the group of panels, dv_panels[] = {10001:01:00; 10002:01:00; etc}; dv_panels2[] = {10001:02:00; 10002:02:00; etc.}) and log it to a text file on the master with the channel number and the device number, along with a date & timestamp. You could go a step further and check that the system is actually running by turning on a flag each time a button is pressed and then turn that flag off in define_program, and log that it turned it off. Think of a ping-pong mechanism, in that if you don't see the "pong" after your "ping" in your log - you found what I call the "Magic Button Sequence" that will kill a system.

Sometimes it's a matter of the sequence of the buttons and changing of variables.

What do you have in define_program? I'd assume quite a bit if you have that high of a CPU marking. If nothing, do you have any modules loaded in there? If so, consider writing your own module, without the define_program baloney they surely put in there.

I'm in the camp that nine times out of ten we create our own problems. Yet, on occasion, there are hardware and firmware issues that are beyond our control.

Good luck & let us know what you find!