Home› AMX User Forum› NetLinx Studio
Options

Your system number is NOT 0

ericmedleyericmedley Posts: 4,177
in NetLinx Studio
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

Comments

  • Options
    DHawthorneDHawthorne Posts: 4,584
    I chuckled at it too. I guess support is fielding a lot of calls on that one.
  • Options
    TurnipTruckTurnipTruck Posts: 1,485
    We may have found the $1,200 question!
  • Options
    Joe HebertJoe Hebert Posts: 2,159
    Can't believe everything you read...
    TN995 wrote:
    When using CONTROL A DEVICE, EMULATE A DEVICE and when setting up DEVICE NOTIFICATION OPTIONS you must enter the real system number.
    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?
  • Options
    binoy.georgebinoy.george Posts: 7
    Is it possible to use control a device with an IP device? I tired it and it did not seem to work, I am wondering if I am doing something wrong.
  • Options
    champchamp Posts: 261
    Not being able to use system 0 in diagnostics has caught me out many times over the years.
    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!
  • Options
    viningvining Posts: 4,368
    binoy.george wrote: »
    Is it possible to use control a device with an IP device? I tired it and it did not seem to work, I am wondering if I am doing something wrong.
    No, AFAIK it still hasn't been supported, there was a good explanation as to why it isn't supported a few months or years ago ?? but I'll be damned if I remember why.
  • Options
    John NagyJohn Nagy Posts: 1,734
    You CAN control an IP device using Control A Device... as long as it presents as an AMX Address. Examples are slave processor's IO ports, the new IP LAN IO boxes from AMX, etc.

    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.
  • Options
    viningvining Posts: 4,368
    John Nagy wrote: »

    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.

    .
    Yeah that can work if you code your module with a data event handler for that virtual which in turn queues the command, opens the socket if it isn't already and then processes the queue to tx to the divice. I usually just create vars and process them in define program for testing strings to the devices , open debug enter a string into a var and set a flag on another var but using a virtual as you described would be cleaner.

    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.
  • Options
    TonyAngeloTonyAngelo Posts: 315
    John Nagy wrote: »
    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.

    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.
Sign In or Register to comment.