Home› AMX User Forum› AMXForums Archive Threads› AMX Hardware

CMessagePipe::Max ??

ariesaries Posts: 27
in AMX Hardware
Howdy all -

I have a NI-3000 based system that has been stable for an age. All of a sudden its basically going deaf and dumb roughly every 24 hours. This system has a MVP-8400 wireless panel which goes off line when this happens. The only fix seems to be a reboot.

The clue is in the show log output.. some kind of queue is filling up.

Anyone have any thoughts as to how to diagnose this? The only IP devices in the system are the MVP-8400. Everything else is RS232.

Thoughts appreciated...

Thanks
-Jim


>show log

Message Log for System 1 Version: v3.30.371
Entry Date/Time Object
Text
1: 04-08-2008 TUE 19:33:43 ConnectionManager
Memory Available = 10042024 <75808>
2: 04-08-2008 TUE 19:33:43 TelnetSvr
Accepted Telnet connection:socket=23 addr=66.181.3.31 port=52981
3: 04-08-2008 TUE 19:30:11 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 325
4: 04-08-2008 TUE 19:28:48 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 300
5: 04-08-2008 TUE 19:27:02 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 275
6: 04-08-2008 TUE 19:24:26 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 250
7: 04-08-2008 TUE 19:19:36 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 225
8: 04-08-2008 TUE 19:19:32 ConnectionManager
No Ping Response (s=1 d=128) wait time=30000 mS
9: 04-08-2008 TUE 19:18:52 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 200
10: 04-08-2008 TUE 19:16:31 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 175
11: 04-08-2008 TUE 19:14:29 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 150
12: 04-08-2008 TUE 19:12:58 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 125
13: 04-08-2008 TUE 19:11:45 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 100
14: 04-08-2008 TUE 19:11:01 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 75
15: 04-08-2008 TUE 19:09:03 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 50
16: 04-08-2008 TUE 19:07:53 Unknown
(Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 25
17: 04-08-2008 TUE 00:09:03 Interpreter
CIpEvent::OffLine 32001:1:1
18: 04-07-2008 MON 22:39:59 Interpreter
CIpEvent::OnLine 128:1:1
19: 04-07-2008 MON 22:39:09 Interpreter
CIpEvent::OffLine 128:1:1
20: 04-07-2008 MON 22:36:47 Interpreter
CIpEvent::OnLine 128:1:1


>

Comments

  • ariesaries Posts: 27
    I should note that a simple "reboot" will not fix this. I usually have to power cycle the system. If I simply do a reboot from the telnet cli the panel will come back online but is otherwise un-responsive. The offending queue starts emitting messages slowly about filling up.

    A cold boot will resolve it.. no messages for usually around 24 hours and fully normal operations. Can't figure out what triggers it. As soon as I get the first message about the queue accumulating messages (ie Max = 25) the system will fail within mere minutes.

    -Jim
  • Jimweir192Jimweir192 Posts: 502
    Do you have anything in the URL list of the master? Also have you got a Gateway IP address set?
  • DHawthorneDHawthorne Posts: 4,584
    CMessagePipe is the mechanism by which devices talk to the master. Something is sending too many messages too fast. My advice is to open a diagnostics connection in either NS or ND, turn on device notifications, and active notifications for all devices and all types. Then watch your traffic.

    If I had to guess, I would say it's a panel feedback problem. Some feedback is being updated way too often, and if the connection to the panel is in any way compromised, even momentarily, the queue backs up. Normal traffic will recover from a connection glitch, but too much can bring it down. This is the most common form this kind of error takes.

    The other strong possibility is an IP communications problem. I had some trouble with an IP to RS-232 adapter that caused this because it dropped off line a lot, and when it did, the process of re-connecting bogged the system down so much my queues got back up to the point of generating that same error. It would often lock th master up entirely; it took me months (and a lot of angry calls from my client) to work out what was going on.
  • ariesaries Posts: 27
    Hi Guys .. thanks for the replies.. some comments:

    Jimweir192: no, nothing in the URL list and no other masters (or slaves) or even AMX gear at all on this particular network besides the TP. There is a default gateway set however the only AMX gear the NI is communicating with by IP is the TP and they are on the same subnet. Next IP address up, infact.

    Dhawthorne: Indeed.. the names of the queues seem'd to suggest this was either an input or output queue for whatever handles communications with the various devices. The TP is the only IP device in this system. Everything else is serial and the updates involving the serial items are not frequent. The TP does receive an update about once a second. I can totally see how this could be a problem if the TP becomes inaccessible for some reason and the NI does not know about it. The NI output queue would build up slowly with events that cannot be consumed by the inaccessible TP. So, I guess the question here is how can I detect this scenario of the TP "going away" and inhibit the events to it? Normally I would have expected the NI to detect a device going offline and inhibit such internally. However, "for fun" I just pulled the batteries out of the MVP8400 TP to simulate an ungraceful failure and it did take the NI some time to notice this. On at least one occasion of trying this it actually caused the very failure I am reporting. So there is very strong evidence this is infact the culprit.

    Do we know how the NI determines online state for IP devices? Does it "ping" them or pass back and forth a keepalive / heartbeat? If so, perhaps the polling frequency can be increased so that offlines are noticed faster? Alternatively is there anything I can do like this within my Netlynx code to, sort of, manually detect an offline panel and inhibit comms? Can netlynx emit an ICMP PING? Lastly, is there any way to clear this message queue from within netlynx?

    Lots of questions! Thanks for the help!

    -Jim
  • Jimweir192Jimweir192 Posts: 502
    As Dave says open Diagnostics and Notifications and see what's happening.

    Do you have any code running in Define_Program?

    Assume your Panel is at 128:1:1?

    Which firmware are you running on the 3000? There was a problem a long while back with queue sizes. You can check the Queue sizes via telnet using 'set queue size' particularly the IP Connection Manager. If you can post your telnet session that may be useful...

    Edit: Sorry you'll need to also look at the 'set thresholds' settings as it's the interpreter thats overflowing
  • ariesaries Posts: 27
    Jim -

    The system version was in my earlier message but reads as: v3.30.371

    The system has not yet failed today so I haven't yet gathered any new information about its failure state. Looking at diagnostics right now during normal operation theres not a whole lot going. The TP gets an update once a second for one item and thats it.

    Panel is at 128:1:1

    No code in define_program

    Here are the set queue size values currently in use:

    >set queue size

    -- This will set the maximum message queue sizes for several threads. --
    -- Use caution when adjusting these values. --
    Set Queue Size Menu

    1. Interpreter (factory default=2000,currently=600)
    2. Notification Manager (factory default=2000,currently=200)
    3. Connection Manager (factory default=2000,currently=500)
    4. Route Manager (factory default=400,currently=200)
    5. Device Manager (factory default=1500,currently=500)
    6. Diagnostic Manager (factory default=500,currently=500)
    7. TCP Transmit Threads (factory default=600,currently=200)
    8. IP Connection Manager (factory default=800,currently=500)
    9. Message Dispatcher (factory default=1000,currently=500)
    10. Axlink Transmit (factory default=800,currently=200)
    11. PhastLink Transmit (factory default=500,currently=500)
    12. ICSNet Transmit (factory default=500,currently=500)
    13. ICSP 232 Transmit (factory default=500,currently=500)
    14. UDP Transmit (factory default=500,currently=500)
    15. NI Device (factory default=500,currently=500)
    Enter choice or press ESC:
    >

    These are the current set threshold values:

    >set threshold

    -- This will set the thresholds of when particular tasks are pended. The --
    -- threshold is the number of messages queued before a task is pended. --
    -- Use extreme caution when adjusting these values. --

    Current Interpreter Threshold = 10
    Enter new Interpreter Threshold (Between 1 and 2000) (Default=1500):
    Current Lontalk Threshold = 50
    Enter new Lontalk Threshold (Between 1 and 2000) (Default=50):
    Current IP Threshold = 200
    Enter new IP Threshold (Between 1 and 2000) (Default=1500):

    New Threshold values specified are identical to current values.
    Thresholds are: Interpreter 10
    Lontalk 50
    IP 200

    No changes are being made.
    >

    I was not able to duplicate the problem today by removing batteries from the panel or failing the wlan. So that may have been a red herring. It does look like the master takes a significant amount of time to notice the TP drop offline. Any way to speed this up? It looks like the TP communicates via TCP (as opposed to UDP).. does AMX use any kind of TCP keep alive probing mechanism? If so, any tunables that could be adjusted to make it more aggressive?

    -J
  • Jimweir192Jimweir192 Posts: 502
    aries wrote: »
    Jim -


    >set queue size


    Set Queue Size Menu

    1. Interpreter (factory default=2000,currently=600)
    2. Notification Manager (factory default=2000,currently=200)
    3. Connection Manager (factory default=2000,currently=500)
    4. Route Manager (factory default=400,currently=200)
    5. Device Manager (factory default=1500,currently=500)
    6. Diagnostic Manager (factory default=500,currently=500)
    7. TCP Transmit Threads (factory default=600,currently=200)
    8. IP Connection Manager (factory default=800,currently=500)
    9. Message Dispatcher (factory default=1000,currently=500)

    Some of these look very low - 1,2,& 5 I would definately increase Device Manager to 1500 to match the default, also in your threshold settings
    Current Interpreter Threshold = 10
    Enter new Interpreter Threshold (Between 1 and 2000) (Default=1500):
    Current Lontalk Threshold = 50
    Enter new Lontalk Threshold (Between 1 and 2000) (Default=50):
    Current IP Threshold = 200
    Enter new IP Threshold (Between 1 and 2000) (Default=1500):
    The Interpreter Threshold should equal the Device Manager Queue size, I thought this was forced in the firmware

    Have a look at TN824
  • ariesaries Posts: 27
    I will make the adjustments and see what happens. While it probably does make sense to have these higher values; I'm concerned that without identifying the root problem all the larger queues will do is make it take longer for the failure to occur.

    -J
  • Jimweir192Jimweir192 Posts: 502
    some of your values are a long way off the defaults... I can't understand why this may be

    The root cause of the overflow is to many messages backing up in the queue, maybe because the interpreter isn't big enough??

    You can see how things are running in a snap shot using the 'show max buffers' command in telnet

    For an NI3000

    >set queue size
    Set Queue Size Menu

    1. Interpreter (factory default=2000,currently=2000)
    2. Notification Manager (factory default=2000,currently=2000)
    3. Connection Manager (factory default=2000,currently=2000)
    4. Route Manager (factory default=400,currently=400)
    5. Device Manager (factory default=1500,currently=1500)
    6. Diagnostic Manager (factory default=500,currently=500)
    7. TCP Transmit Threads (factory default=600,currently=600)
    8. IP Connection Manager (factory default=800,currently=800)
    9. Message Dispatcher (factory default=1000,currently=1000)
    10. Axlink Transmit (factory default=800,currently=800)
    11. PhastLink Transmit (factory default=500,currently=500)
    12. ICSNet Transmit (factory default=500,currently=500)
    13. ICSP 232 Transmit (factory default=500,currently=500)
    14. UDP Transmit (factory default=500,currently=500)
    15. NI Device (factory default=500,currently=500)

    >set threshold

    New Threshold values specified are identical to current values.
    Thresholds are: Interpreter 1500
    Lontalk 50
    IP 1500

    No changes are being made.
  • DHawthorneDHawthorne Posts: 4,584
    There has always been an issue with devices going off line before the processor realizes it. Some devices are better at being detected than others, but Axlink ones are the worst ... and by your device numbers, that seems to be your case. Axlink is also very slow (relative to ICSNet or Ethernet). SO , it could very well be nothing is actually wrong except the queue and threshold values are too small to buffer the slowdowns.

    Once a second is not a lot of activity at all. If you have 100's of messages a second, that I would say needs trimming, but a master can easily handle a few score per second.
  • Jimweir192Jimweir192 Posts: 502
    You have your MVP8400 panel at 128 rather than the default range of 10001, although the device no shouldn't make any difference...
  • ariesaries Posts: 27
    Guys -

    Just caught the system fail right as I was watching! Almost never happens this way.. however; it doesnt really seem to help as nothing was going on. Doesn't seem anything visible triggered it. It just, well, stopped working!.

    Here are the last messages shown in Netlinx Diagnostics (I've been keeping it open hoping for just such an occurance). If you look at line 3665 -- this is the last message sent to the panel. All of the messages that follow are messages from the panel which are me pressing a button several times to see if the messages were going out and being received. That they show in the diganostic seems to indicate that they are received. The processor is deaf to these messages -- ie though the messages are obviously received by the hardware and make it far enough to show up in diganostics the netlinx program does not process the event handlers for them.

    The system was idle at this time; only sending a periodic update that shows the time on the panel.

    Line 3653 :: Command To [128:1:1]-[^BMF-10,0,%T9:27:24 PM] - 21:27:50
    Line 3654 :: Feedback:Off [128:1:1] - Channel 107 - 21:27:51
    Line 3655 :: Output Channel:Off - From [128:1:1] - Channel 107 - 21:27:51
    Line 3656 :: Command To [128:1:1]-[^BMF-10,0,%T9:27:25 PM] - 21:27:51
    Line 3657 :: Feedback:On [128:1:1] - Channel 2 - 21:27:51
    Line 3658 :: Output Channel:On - From [128:1:1] - Channel 2 - 21:27:51
    Line 3659 :: Command To [128:1:1]-[^BMF-10,0,%T9:27:26 PM] - 21:27:52
    Line 3660 :: Feedback:Off [128:1:1] - Channel 1 - 21:27:52
    Line 3661 :: Output Channel:Off - From [128:1:1] - Channel 1 - 21:27:52
    Line 3662 :: Command To [128:1:1]-[^BMF-10,0,%T9:27:27 PM] - 21:27:53
    Line 3663 :: Command To [128:1:1]-[^BMF-10,0,%T9:27:28 PM] - 21:27:54
    Line 3664 :: Feedback:Off [128:1:1] - Channel 2 - 21:27:54
    Line 3665 :: Output Channel:Off - From [128:1:1] - Channel 2 - 21:27:54
    Line 3666 :: Input Status:Pushed [128:1:1] - Channel 226 - 21:29:10
    Line 3667 :: Input Status:Released [128:1:1] - Channel 226 - 21:29:11
    Line 3668 :: Input Status:Pushed [128:1:1] - Channel 226 - 21:29:11
    Line 3669 :: Input Status:Released [128:1:1] - Channel 226 - 21:29:12
    Line 3670 :: Input Status:Pushed [128:1:1] - Channel 226 - 21:29:12
    Line 3671 :: Input Status:Released [128:1:1] - Channel 226 - 21:29:12


    Here is the "show log" output at this exact time:

    Message Log for System 1 Version: v3.30.371
    Entry Date/Time Object
    Text
    1: 04-11-2008 FRI 21:28:47 Unknown
    (Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 50
    2: 04-11-2008 FRI 21:05:38 Interpreter
    CIpEvent::OnLine 32001:1:1
    3: 04-11-2008 FRI 20:59:15 Interpreter
    CIpEvent::OffLine 32001:1:1
    4: 04-10-2008 THU 22:49:37 TelnetSvr
    Accepted Telnet connection:socket=29 addr=66.181.xx.xx port=53925
    5: 04-10-2008 THU 15:00:00 Interpreter
    "SendInsteon sending setOnLevel"
    6: 04-10-2008 THU 15:00:00 Interpreter
    Running event MB-OFF
    7: 04-10-2008 THU 14:00:00 Interpreter
    "SendInsteon sending setOnLevel"
    8: 04-10-2008 THU 14:00:00 Interpreter
    Running event FL-ON
    9: 04-10-2008 THU 11:15:00 Interpreter
    "SendInsteon sending setOnLevel"
    10: 04-10-2008 THU 11:15:00 Interpreter
    Running event SN-ON
    11: 04-10-2008 THU 11:00:00 Interpreter
    "SendInsteon sending setOnLevel"
    12: 04-10-2008 THU 11:00:00 Interpreter
    Running event MB-OFF
    13: 04-10-2008 THU 09:00:00 Interpreter
    "SendInsteon sending setOnLevel"
    14: 04-10-2008 THU 09:00:00 Interpreter
    Running event FA-OFF
    15: 04-10-2008 THU 06:30:00 Interpreter
    "SendInsteon sending setOnLevel"
    16: 04-10-2008 THU 06:30:00 Interpreter
    Running event HLL-OFF
    17: 04-10-2008 THU 06:00:00 Interpreter
    Running event PTO-OFF
    18: 04-10-2008 THU 01:30:01 Interpreter
    "SendInsteon sending setOnLevel"
    19: 04-10-2008 THU 01:30:01 Interpreter
    Running event SN-OFF
    20: 04-10-2008 THU 01:00:00 Interpreter
    "SendInsteon sending setOnLevel"

    This is the show log from the panel.. all seems ok:

    Message Log
    Entry Date/Time Level Object
    Text
    1: 04-11-2008 FRI 21:28:48 Info memory
    ManUsage=4394K Free=26992K

    2: 04-10-2008 THU 22:32:22 Info memory
    ManUsage=4394K Free=27248K

    3: 04-10-2008 THU 20:10:53 Info memory
    ManUsage=4384K Free=27256K

    4: 04-10-2008 THU 20:10:43 Info memory
    ManUsage=4384K Free=27292K

    5: 04-10-2008 THU 00:21:08 Info memory
    ManUsage=4384K Free=27348K

    6: 04-10-2008 THU 00:20:58 Info memory
    ManUsage=4385K Free=27352K

    7: 04-09-2008 WED 22:28:11 Info memory
    ManUsage=4383K Free=28264K

    8: 04-09-2008 WED 22:27:41 Info memory
    ManUsage=4378K UnManUsage=140K Free=29600K

    9: 04-09-2008 WED 22:27:36 WARN border
    BorderData Error=6 style=[Line Single] basefile=[]

    10: 04-09-2008 WED 21:56:19 Info memory
    ManUsage=4376K UnManUsage=167K Free=33520K

    11: 04-09-2008 WED 21:56:18 Info setup
    Master CONNECTED 66.181.xx.xx

    12: 04-09-2008 WED 21:53:03 Info setup
    Master DISCONNECTED

    13: 04-09-2008 WED 21:53:03 Info setup
    Master DISCONNECTED

    14: 04-09-2008 WED 21:52:29 Info memory
    ManUsage=4358K Free=33796K

    15: 04-09-2008 WED 21:52:19 Info memory
    ManUsage=4358K UnManUsage=140K Free=33800K

    16: 01-01-1970 THU 00:00:27 Info setup
    Master CONNECTED 66.181.xx.xx

    17: 01-01-1970 THU 00:00:26 Info desktop
    Web Control Server is running port=5900

    18: 01-01-1970 THU 00:00:26 Info phal
    EventLoop tid=15376

    19: 01-01-1970 THU 00:00:26 Info cache
    GfImageCacheManager Sizing Colororized Cache: old 2048 kB: new 3224 kB

    20: 01-01-1970 THU 00:00:26 Info cache
    GfImageCacheManager Sizing State Cache: old 8192 kB: new 11287 kB

    --

    Here is the show connection log on the panel:

    >show connection log

    Connection Log
    Entry Date/Time Event
    Text
    1: 04-09-2008 WED 21:56:18 MasterUrlConnect
    Connected to (Sys=1) Master 66.181.xx.xx (URL Mode)

    2: 04-09-2008 WED 21:56:15 SocketError
    Socket connect attempt failed: Connection timed out (errno=0x91)

    3: 04-09-2008 WED 21:53:06 SocketClosure
    ICSPTCP End

    4: 04-09-2008 WED 21:53:03 MasterUrlConnect
    Disconnected from (Sys=0) Master 66.181.xx.xx (URL Mode)

    5: 04-09-2008 WED 21:53:03 MasterUrlConnect
    Disconnected from (Sys=0) Master 66.181.xx.xx (URL Mode)

    6: 04-09-2008 WED 21:53:03 SocketError
    ICSP TCP Socket read error: iBytesRead==0

    7: 04-09-2008 WED 21:53:03 IcspMsgTimeout
    Closing connection due to ICSP Message timeout

    8: 04-09-2008 WED 21:52:58 BlinkMissTimeout
    Blink Messages Missed

    9: 04-09-2008 WED 21:52:44 BlinkMissTimeout
    Blink Messages Missed

    10: 01-01-1970 THU 00:00:27 MasterUrlConnect
    Connected to (Sys=1) Master 66.181.xx.xx (URL Mode)

    ---

    Here is the show connection stats from the panel

    >show connection stats

    Connection Statistics
    Total Last 15 Minutes
    ===== ===============
    ICSP Messages: 1280023 received 4022 received
    1280015 processed 4022 processed
    8 dropped 0 droppped


    Blink Messages: 34377 received 136 received
    2 missed 0 missed


    IP Statistics:

    RX packets:418203 errors:0 dropped:0 overruns:0 frame:0
    TX packets:331695 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    RX bytes:38906985 (37.1 Mb) TX bytes:21832327 (20.8 Mb)


    Wireless Statistics:

    Mode:Managed Frequency:2.422 GHz Access Point: 00:1E:52:78:81:B5
    Link Quality=90/100 Signal level=94/255 Noise level=166/152
    Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:513328
    Tx excessive retries:14879 Invalid misc:24864 Missed beacon:0


    >
    ---

    The master can ping the IP based touch panel:

    >ping 66.181.xx.xx
    66.181.xx.xx is alive.
    >


    Not quite sure what gives here!

    Anything else I can capture logs or snapshots of that might help clear it up?


    Thanks!

    -Jim
  • ariesaries Posts: 27
    ALso, I should add.. simply rebooting the master will not clear it. Ie, if I telnet in and type "reboot"; it will reboot and eventually the panel will come back online. But the system still will not respond.

    This is what I see right after a reboot:

    >show log

    Message Log for System 1 Version: v3.30.371
    Entry Date/Time Object
    Text
    1: 04-11-2008 FRI 21:55:35 ConnectionManager
    Memory Available = 10150796 <70272>
    2: 04-11-2008 FRI 21:55:34 TelnetSvr
    Accepted Telnet connection:socket=28 addr=66.181.xx.xx port=54647
    3: 04-11-2008 FRI 21:54:38 Unknown
    (Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 75
    4: 04-11-2008 FRI 21:54:03 Unknown
    (Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 50
    5: 04-11-2008 FRI 21:53:22 Unknown
    (Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 25
    6: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 128:1:1
    7: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:17:1
    8: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:16:1
    9: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:15:1
    10: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:14:1
    11: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:13:1
    12: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:12:1
    13: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:11:1
    14: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:10:1
    15: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:9:1
    16: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:8:1
    17: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:7:1
    18: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:6:1
    19: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:5:1
    20: 04-11-2008 FRI 21:52:48 Interpreter
    CIpEvent::OnLine 5001:4:1


    Of course a cold boot (power cycle) does result in the system coming back to life.

    -J
  • ariesaries Posts: 27
    Well, think I may have gotten it solved! Seems I could reproduce it by disconnecting a serial cable that was connected between com port 8 and a ******** processor (the two collaborate in this system). The ******** wasnt sending any data -- an update every 10 sec or so. But it seems as soon as I plug this cable into the NI this issue would occur. No clue why. No data was being sent. Had debug monitors open on both the ******** and AMX sides.. nothing there. No lights flashing on the com ports on either unit. Quite a mystery. Tried a different AMX com port thiniking maybe somehow the com port hardware went bad.. nope.

    Simply creating a new serial cable so far has cured it.

    I have absolutely no clue how this could impact anything. Netlinx diagnostics did not show anything going on with the com ports.

    Most bizarre.

    Anyway, I'm curious to know if anyone has any clues how this could be a cause of such a problem?

    Thanks!
    -Jim
  • Jimweir192Jimweir192 Posts: 502
    What pins were you using on the serial cable? Is it a molded cable?
  • ariesaries Posts: 27
    Not sure which pins were wired through.. its an off the shelf molded serial cable. The new cable I made used pins 2,3 and 5.

    -J
  • Jimweir192Jimweir192 Posts: 502
    Never use a moulded cable on an NI Master - the 9pin is non-standard and shares pins for 422/485 as well as 2,3 & 5 for RS232 - it will always result in wierd behaviour or non-operation.

    Glad you sorted your issue!
  • AuserAuser Posts: 506
    aries wrote: »
    Seems I could reproduce it by disconnecting a serial cable that was connected between com port 8 and a ******** processor [...]

    Maybe DDDP was recognising what was connected and the NetLinx was refusing to work, hee hee :D

    On a more useful note, I'm curious to know where com 8 lives in the system? Is that an NXC-COM2 in an ICSNET frame?
Sign In or Register to comment.