DEV array: Adding and removing devs at runtime
colind
Posts: 4
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
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
0
Comments
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.
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
Thanks,
Colin
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.
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
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.
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.
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
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.
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.
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.