Telnet into an NI-x master and issue the command spy from the prompt. I believe it?s an undocumented AMX diagnostic tool. I?ve never been able to find out anything about it (other than it exists) so I don?t know how to interpret the results.
I?m not sure why Kim says it?s a bad command, I?m pretty sure it?s just a tool.
Telnet into an NI-x master and issue the command spy from the prompt. I believe it?s an undocumented AMX diagnostic tool. I?ve never been able to find out anything about it (other than it exists) so I don?t know how to interpret the results.
I?m not sure why Kim says it?s a bad command, I?m pretty sure it?s just a tool.
I just tried it on a master and got the 'unknown command' result. It must be on newer firmware or something.
It's documented, just use the help command from telnet.
When I run it here with a NI-3100 running v3.5.430 it drops it's TCP connection to the touch panel. Haven't got any RS-232 or AxLink devices attached to this one at the moment so I can't confirm whether they drop as well.
That's my problem. I'm on an NI 3000 with older firmware. I knew of the command now that I think about. A tech support person asked me to type it. In UNIX theccommand is for listng all logged in users. Perhaps it's the same thing.
spy is a VxWorks tool that was added in the more recent firmware releases. It is a diagnostic tool for tracking CPU usage per task. It is really only of use by AMX engineering...or possibly by Duet module writers...in trying to determine if a particular task is hogging the CPU. I don't have an explanation as to why panel connections would drop. I will say that the spy tool is in itself very CPU intensive. In its default mode it sucks 15% of the CPU. But beyond that, the tool itself should be innocuous. It does not affect the execution of the rest of the controllers firmware tasks...other than starving them of some CPU. I suppose if the system was already marginal and the tasks servicing the panel connection were starved, this could cause a panel to drop offline.
For the average NetLinx programmer, spy is of no use.
spy is a VxWorks tool that was added in the more recent firmware releases. It is a diagnostic tool for tracking CPU usage per task. It is really only of use by AMX engineering...or possibly by Duet module writers...in trying to determine if a particular task is hogging the CPU. I don't have an explanation as to why panel connections would drop. I will say that the spy tool is in itself very CPU intensive. In its default mode it sucks 15% of the CPU. But beyond that, the tool itself should be innocuous. It does not affect the execution of the rest of the controllers firmware tasks...other than starving them of some CPU. I suppose if the system was already marginal and the tasks servicing the panel connection were starved, this could cause a panel to drop offline.
For the average NetLinx programmer, spy is of no use.
I find the manager of resources or the spy, the interesting utility. Especially in those cases when АМХ hangs and leads the life that happens... But developers АМХ consider have not worked having written a new code to write to it instructions, with the description of all processes and for what they answer... And the controller all the same hangs after a call of this command. The bulb the status burns constantly does not blink...
Comments
Hmm...
which command are you speaking of?
I?m not sure why Kim says it?s a bad command, I?m pretty sure it?s just a tool.
I just tried it on a master and got the 'unknown command' result. It must be on newer firmware or something.
When I run it here with a NI-3100 running v3.5.430 it drops it's TCP connection to the touch panel. Haven't got any RS-232 or AxLink devices attached to this one at the moment so I can't confirm whether they drop as well.
This is a sample output:
For the average NetLinx programmer, spy is of no use.
It still drops connection when the box is empty (no code).
I find the manager of resources or the spy, the interesting utility. Especially in those cases when АМХ hangs and leads the life that happens... But developers АМХ consider have not worked having written a new code to write to it instructions, with the description of all processes and for what they answer... And the controller all the same hangs after a call of this command. The bulb the status burns constantly does not blink...