Home AMX User Forum NetLinx Studio

DEV array: Adding and removing devs at runtime

Noobie question:
How can I add and remove devices from a device array during runtime? I've tried the usual array keywords:
devA[0] = null
devA[1] = TP3
but it doesn't compile. Is there a better help file on device arrays than the netlinx keyword help in Netlinx studio?

Thanks,
Colin

Comments

  • mpullinmpullin Posts: 949
    colind wrote:
    Noobie question:
    How can I add and remove devices from a device array during runtime? I've tried the usual array keywords:
    devA[0] = null
    devA[1] = TP3
    but it doesn't compile. Is there a better help file on device arrays than the netlinx keyword help in Netlinx studio?

    Thanks,
    Colin
    Not sure why you would want to do this, but you could try creating a virtual device to do nothing (e.g. vdvNULL = 33000:1:0) and assigning the cells of your array to that device. e.g. devA[1] = vdvNULL; devA[2] = dvTP3; devA[3] = vdvNULL; etc. There is no null keyword in NetLinx.

    Also, arrays in Netlinx are one-based, not zero-based. Trying to access the 0th cell of an array will throw an error regardless of what you're trying to put there.
  • Re: Adjusting Dev Array's in Real time

    This is very possible, as a matter of fact, its something I figured out the hard way on a job and have used succesfully on several others.

    Step 1:

    Create a vdvNULL with an unused and safe device number
    Create a virtual device to be the primary interface to the Dev Array
    Create the array with the proper number of dev locations

    Step 2:

    Populate the array as required, either with other dev's or the null

    Step 3:

    Combine the virtual device with your array using Combine_device

    Step 4:

    When you need to adjust the array, uncombine the virtual device from your array with Uncombine Device
    Manipulate your dev array as required
    Recombine the virtual device with your array using Combine_device

    A few caveats:
    Use dev arrays that are as small as possible
    Do as little of this as you can, as the uncombine/manipulate/combine is not as speedy as one would like, so the less you do it, the less latency you will experience.
    I've found that I can successfully manipulate about 5-8 combines simultaneously with 3-7 elements in the arrays without affecting the user experience in my code.

    I can post some code snippets some other time if you need more direction.

    Brad Odegard
  • colindcolind Posts: 4
    Thanks for the tip. My intention was to create a dev array for each source device (dvd, xm, etc.). When the user of TP3 selects to control xm, TP3 is added to the XM dev array. When the user selects DVD TP3 is removed from the xm dev array and added to the DVD array. That way all my device controls use the same port so I can copy and paste at will when building UIs. Is there a better method for doing this?

    Thanks,
    Colin
  • DHawthorneDHawthorne Posts: 4,584
    I've been around the block a few times with this kind of thing, and am still not completely satisfied that I have done the most efficient or most elegant thing.

    If you want to create individual device virtuals, the method Brad spelled out works pretty well; I've done exactly as he describes. Put it in it's own function, and it's very easy to implement. As he mentioned, there is a performance hit, but it's tiny, so unless you have a boatload of it going on, it's not enough to worry about.

    Another way of doing it is to just put every device on its own port in the panel. It's rather trivial, to my way of thinking, to select all the buttons on a page and change the port. However, it gets pretty unwieldy in a big system with all the panel device definitions.

    Yet a third way is to branch your button events in such a way that your code tracks the device and send it to the right place.

    What I have settled on is a compromise. If it's an RS-232 device, or IP device, I give it it's own port. IR devices I lump all together; the panels have the same ports and channels on the buttons, and the code sends them to the appropriate device depending on what's active. I don't use the virtual trick anymore. I'm not really sure why; it just seemed easier to keep track of what was going on in the code without having to worry about what device was combined with which panel pages at any moment.
  • Re: Dev Arrays

    I don't know that I would choose to do this for situations where I had control of things. The reason I implimented this was to handle the situation with pre-built modules with UI code that normally specify one instance of the UI module for each TP you want to have control. I found on a job with many TP's that the instances of the module were creating problems. So I did this instead: I have one instance of the UI module for each "zone" i want to control (so for an ADA tunesuite, you might have 4 instances of the UI module) Then I move the physical TP's into and out of the DEV array depending on if that TP is meant to control that zone of the source.

    I found this to be more efficient, particularly when I had 10-15 TP's in a system. It seemed better to me to have 4 instances of the UI module for a tunesuite than 10-15 of them.

    I follow a similar plan to Mr. Hawthorne in that I use as many common channels between IR devices and just route the code internally to the correct output. For some other devices like the ARQ and some security, I'll use seperate port numbers, but like him I find that too many ports on a given TP gets ungainly in a hurry.

    Brad
  • My instinct says do it programmatically - write some code to decide which module to send each button push to.

    There are so many things you might want to do with a button push (feedback, debug, navigation, reset a sleep timer, refresh display, etc) that it's very handy to process all incoming button pushes in a single routine - and have that do routing too.
  • colindcolind Posts: 4
    Brad,

    Why step 3? What does the Combine Device do that the device array does not?

    Thanks,
    Colin
  • DHawthorneDHawthorne Posts: 4,584
    colind wrote:
    Brad,

    Why step 3? What does the Combine Device do that the device array does not?

    Thanks,
    Colin

    We are talking about a module that doesn't address the device array, but a single virtual device. Combining the array with the virtual causes all the devices in the array to respond to activity on the virtual; however, if the array changes, you have to uncombine and recombine to make the module work with the changed array.
  • Re: Dev Array maniupulation

    Dave is correct,

    In the instances I'm using this function, I use the Dev Arrays to interface with the UI modules which are only written to function with a single device, not a dev array, so I create a virtual device that is passed to the module code, and then manage the combine / manipulate / uncombine in my glue code. If the item you were interfacing to was written from the ground up to handle the dev array natively, you could probably skip the virutal interface, but I think it's probably easier to do this way than the other.

    Brad
  • AlexArtistAlexArtist Posts: 51
    mpullin wrote: »
    Not sure why you would want to do this, but you could try creating a virtual device to do nothing (e.g. vdvNULL = 33000:1:0) and assigning the cells of your array to that device. e.g. devA[1] = vdvNULL; devA[2] = dvTP3; devA[3] = vdvNULL; etc. There is no null keyword in NetLinx.

    Also, arrays in Netlinx are one-based, not zero-based. Trying to access the 0th cell of an array will throw an error regardless of what you're trying to put there.

    for a null device couldn't you just do something like dvNull = 0:0:0 ?

    If you use a virutal device like vNull = 33000:1:1
    if you do a push on it and if vNull is part of an event table, it will cause an event.

    I don't think dvNull = 0:0:0 will trigger events. Someone may want to test this out.
  • mpullinmpullin Posts: 949
    AlexArtist wrote: »
    for a null device couldn't you just do something like dvNull = 0:0:0 ?

    If you use a virutal device like vNull = 33000:1:1
    if you do a push on it and if vNull is part of an event table, it will cause an event.

    I don't think dvNull = 0:0:0 will trigger events. Someone may want to test this out.

    I thought sending commands to 0:0:0 affects the local master, but I was wrong, I just sent the command REBOOT to 0:0:0 on an active system and it did not reboot.

    In conclusion, 0:0:0 appears to be acceptable for a null device.
  • ericmedleyericmedley Posts: 4,177
    mpullin wrote: »
    I thought sending commands to 0:0:0 affects the local master, but I was wrong, I just sent the command REBOOT to 0:0:0 on an active system and it did not reboot.

    In conclusion, 0:0:0 appears to be acceptable for a null device.

    If you send the command REBOOT(0) from the program it'll work.

    Perhaps it's just me being superstitious, but I've never liked the idea of sending commands to 0. I don't know why. I just create a virtual device for such things. To me it's from the old Z80 days of avoiding programming habits where you 'might' be operating in the unknown. Your commands probably won't do anything, but who knows. I can run diagnostics on the virtual device just as easily and watch internal messages at the same time.
  • a_riot42a_riot42 Posts: 1,624
    DHawthorne wrote: »
    What I have settled on is a compromise. If it's an RS-232 device, or IP device, I give it it's own port. IR devices I lump all together; the panels have the same ports and channels on the buttons, and the code sends them to the appropriate device depending on what's active. I don't use the virtual trick anymore. I'm not really sure why; it just seemed easier to keep track of what was going on in the code without having to worry about what device was combined with which panel pages at any moment.

    That's pretty much exactly as I do it and it seems to work well. I use vdvNull = 0:0:0 as my null device and haven't had any issues like accidentally creating a black hole.
    Paul
  • DHawthorneDHawthorne Posts: 4,584
    a_riot42 wrote: »
    That's pretty much exactly as I do it and it seems to work well. I use vdvNull = 0:0:0 as my null device and haven't had any issues like accidentally creating a black hole.
    Paul

    I've never had any trouble using 0:0:0 either, though I usually call it something like dvDebug. However, I've moved on to making a virtual device standardized to 33001:1:0 for that. The reason is I can attach a string handler to it so I can remotely query the system for status feedback.
Sign In or Register to comment.