Set_virtual_channel_count feedback

richardherman

Hello,

I have a NI-4100 with 2 1200 TP's programmed identical. These panels are 'combined':
COMBINE_DEVICES (vdvTP, dvTP1, dvTP2)
Because the first panel in the list has to be a virtual one, and the real panels have more than 255 channels i have added the following statement in the DEFINE_START section:
SET_VIRTUAL_CHANNEL_COUNT (vdvTP, 1024)

During normal operation this works fine. But when do a 'cold reboot' (recycle power) the feedback is 'weird'. Channels below 255 seem ok, but higher channel numbers give unreliable feedback: some work and some don't. Even real simple ones like [vdvTP,444] = 1 do not work. When this happens, it seems that a 'warm reboot' (reboot from NS2 or telnet) is enough to solve the problem.

has anyone experienced this? Is there maybe a way to avoid this?

Is is annoying that everytime a client has a power failure, i have to do a 'warm reboot'

Richard

Marc Scheibein

No real idea, but....

Maybe it is a timing issue with the cold reboot and the DEFINE_START.
Try to set the channel count in the Online Event of the virtual device

DEFINE_EVENT
DATA_EVENT[vdvTP]
{
ONLINE:
{
SET_VIRTUAL_CHANNEL_COUNT(vdvTP,1024)
}
}

But I'm pretty sure that I did it several times in your way in the past....

richardherman

Hello Marc, Thanks for the answer.

I did write the program exactly as you described. When that didn't seem to work i did some searching and concluded that the DEFINE_START section maybe was a better place for it. Unfortunately that did not work either. So i posted here....

As a sidenote: when i check the the port status for the vdvTP device it never has the number of channels i assigned it. When ie i do a SET_VIRTUAL_CHANNEL_COUNT (vdvTP,1024) it reports 1280 channels (right, that's 256 too high). I haven't really looked into this, it just seems somewhat strange.

Anyway, thanks for the idea,

Regards,

Richard

Marc Scheibein

I can remember that set_virtual_channel_count() is establishing something like a "multiple of 256" corresponding to the "high" channel defined in the function.
1024+256 = 1280 // because channel 0 is also counted, you "request" 1025 channels, and so the next block is 1280

adys

I have the same problem... any solution found?

http://www.amxforums.com/showthread.php?t=3746

Auser

Hi Richard,

Weirdness.

I've always put the set_virtual_channel_count statement in the online event for the virtual device as Marc has described and never had a problem. Nor am I aware of any difference between power cycling a NetLinx and doing a warm boot.

The only thing I can suggest is watching the red output LED on the controller when it's in the fault state to see if your code is trying to set the problem channels to differing values at different points which are being called regularly (ie. from mainline). If it's on solid, that's a pretty good indicator; device notifications should show you what channel(s) are affected if this is case.

richardherman

Hello Auser,

Weirdness indeed

>I've always put the set_virtual_channel_count statement in the online event for the virtual device as Marc has described and never had a problem. Nor am I aware of any difference between power cycling a NetLinx and doing a warm boot.

Neither am i. But AMX does not give any information about the starting procedure of a Netlinx controller (that i am aware off), so i really don't know.

>The only thing I can suggest is watching the red output LED on the controller when it's in the fault state to see if your code is trying to set the problem channels to differing values at different points which are being called regularly (ie. from mainline). If it's on solid, that's a pretty good indicator; device notifications should show you what channel(s) are affected if this is case.

No, the output led is is not ON. One example: on the TP's there's a button (345) that's completely transparant in it's ON state (invisible) and shows the text 'NO CONTACT' in it's OFF state. In mainline (and nowhere else) there is 1 command: ON[vdvTP,345]. So when the TP has 'contact' with the controller, the button will always be ON. This simple statement does not work, ever, after plugging in the power.After rebooting the controller all seems ok.

I have (almost) the same setup, on multiple locations, but with only one TP (no combine) en there it works fine.

But thanks for the idea.

Richard

Auser

Two other thoughts (clutching at straws without the code in front of me):

- You're not working with a virtual device port other than one by any chance? If vdvTP in your snippet below is something like 33001:2:0, you won't be able to do anything with it until you use set_virtual_port_count to set the number of ports on device 33001, as virtual devices only have one port by default. Doesn't look like it from the code snippets below, but thought I'd mention it.

- I suspect that there may be an issue combining the virtual device with the physical devices and then increasing the number of channels on the virtual device using set_virtual _channel_count. I don't usually use combine_devices to join virtual and physical devices together for various reasons (I normally use device arrays) and am too lasy to scratch up some test code but possible solutions I can think of are as follows:

// Instead of 
COMBINE_DEVICES (vdvTP, dvTP1, dvTP2)
SET_VIRTUAL_CHANNEL_COUNT (vdvTP, 1024)

// Try
SET_VIRTUAL_CHANNEL_COUNT (vdvTP, 1024)
COMBINE_DEVICES (vdvTP, dvTP1, dvTP2)

// Or
COMBINE_DEVICES (vdvTP, dvTP1, dvTP2)
SET_VIRTUAL_CHANNEL_COUNT (vdvTP, 1024)
rebuild_event()

This could explain what you're seeing when you cold boot the control system - it could be that virtual devices persist/are non-volatile on warm boots, including level/channel/port counts, but not on power cycles.

richardherman

Hello Auser,

You're right, i'm not using a virtual device port. If i did it still wouldn't work after a reboot.

Auser wrote:

This could explain what you're seeing when you cold boot the control system - it could be that virtual devices persist/are non-volatile on warm boots, including level/channel/port counts, but not on power cycles.

Now that's a thought. I like it, it makes sense. I will try one of your possible solutions (or something equivalent). It probably will take some time but i'll report back with the results.

Thanks,

Richard

PS: maybe this will be a solution for 'adys' too (see above). If he is still working on the system maybe he can test this.

adys

I didn't undestand ...

I don't have any COMBINE_DEVICES in my code, and I set all the set_virtual_ports_count and set_virtual_channel_count in the START section (as I was told by support)

I am working on this issue , I will update as soon as I will have solution.

DHawthorne

I had a similar issue with panels in a multi-master system. It would seem that to control a panel defined on a remote master, a local, hidden virtual is used to represent it, and all the level and channel limits apply even though it refers to an actual device.

I had to put my SET_VIRTUAL... commands in the online event handler for the panels. It still didn't quite work, until I set a flag with a volatile variable when the master rebooted, then rebooting the panel once again after the master had settled down. There is definitely some weird timing issue, but for me that did it consistently.

Daniel Tehan

Try switching to a device array ?

I have had similar problems in the past, I found the same result that rebooting the panel after the master had finished its boot process fixed it. I never tried changing the number of channels on the virtual, I just replaced my virtual device with a device array and everything worked perfectly. Depending on the code you have written this may or may not be easy, but a search and replace with a couple of different lines of code at the top did it for me.

Auser

Daniel Tehan wrote: »

... I just replaced my virtual device with a device array and everything worked perfectly.

Good tip. I only ever really use combine_<whatever> to connect a <whatever> on a remote system to a local virtual device so that the values don't get lost when the remote device associated with the <whatever> goes offline.

richardherman

To Auser:

I tried your suggestion to increase the channel count and THAN combining the devices, but unfortunately that didn't work. I will try switching to a device array and see how that works.

The system is >200km away and in heavy use every day so it will take a while but i'll report back.

Thanks for the suggestions.

Richard

Auser

richardherman wrote: »

I tried your suggestion to increase the channel count and THAN combining the devices, but unfortunately that didn't work.

What a pity. Best of luck in getting to the bottom of it.

richardherman

It took a while, but 2 weeks ago i switched over from COMBINE_DEVICES to a dev array and that seems to solve the problem. Feedback is correct after a 'cold boot'.

Thanks to everyone who gave suggestions and helped solving this.

Richard Herman