Your system number is NOT 0
ericmedley
Posts: 4,177
The latest tech note struck me as funny for some reason. Something like "where's the ANY key".
Your system number is NOT 0
5 users say this is 3 out of 5 Stars
When using the different tools in NetLinx Studio for troubleshooting and file transfer there is often a mistake made in entering your system number. Your system number is NOT 0, you need to enter your REAL system number during these procedures. 0 as a system number is a programming "WILD CARD" per say, when writing your code and using 0 as the system number you are making your code "PORTABLE" this will allow the code to run on any master it is loaded to and it will adopt that system number.* A "REAL" system number will be between 1 and 65,535.
*
During a file transfer it is not necessary to enter a real system number, however if you are loading code to a master that is part of a master to master configuration and you enter 0 as your system number you are going to load the code to the master you are currently connected to. Therefore by entering your REAL system number you are ensuring a file transfer to the correct master.
*
When using CONTROL A DEVICE, EMULATE A DEVICE*and when setting up DEVICE NOTIFICATION OPTIONS you must enter the real system number.
Downloads
0
Comments
The tech note is not entirely accurate. You can use system 0 for Emulate a Device the same as you can use 0 for file transfers. I never understood the inconsistency of why Control a Device and Device Notifications require the real system number. Why not let System 0 be the *this* pointer all around?
I'd guess that the time lost to support calls over the years would be much greater than the time it would take to resolve the issue.
Why invest time in an IDE for developers who don't buy and sell your products, it's not like AMX products don't do anything without a developer to write software for them...
I'm going to hold my breath until you admit that I am not stubborn!
You can't use CONTROL A DEVICE to control a device that's not a device with an AMX address.
So, no you can't simply dial in a KSCAPE or TIVO on IP and toss it commands using the NLS "Control a device", what AMX device address/port/system would you imagine you would be using?
If your code created an AMX virtual device (with an address and a system presence on the tree) that handed off to an IP device, then CONTROL A DEVICE ought to work.
I think. I'm willing to be completely corrected, and learn something new.
For control device to work on IP devices you could use the defined dps 0:x:x but you would also need to provide a port for the device and whether the connection is tcp or udp. Then control device would need the ability to open the socket and tx on the online event. Might also need to provide fields in control a device for login credentials. AMX probably figures you can do all this already with PuTty or Indigo so why bother building it into NS3. Of course as more and more devices go IP maybe a future version of NS will better IP tools built in.
Or, you can setup a send_string to the device in question as a channel_event and pulse that using "control a device". To send any string you can add a variable to the send_string and alter it your hearts content in debug.
Because of issues I've had in the past with "control a device" not handling certain characters well I do this for serial devices too.