Level Event Problem

zerodev

After searching the forums and coming up empty, I thought I'd give this a try.

I've built a module that handles volume controls, and I am using Level Events to handle feedback. Here is my code:

MODULE:

select
{
active (FIND_STRING(cResponse, "'Vol'", 1)):
{
nVolumeFB = atoi(cResponse)
SEND_LEVEL vdvDev, PROGRAM_VOLUME_FB, nVolumeFB
}
}

PROGRAM:

LEVEL_EVENT [sDevice[2].vdvDevice, PROGRAM_VOLUME_FB]
{
SEND_LEVEL dvPanels1, Level.Input.Level, Level.Value
}

I have had no issues in the past doing this sort of thing, but all of a sudden this does not work. I am seeing the level change coming from the module, but for whatever godforsaken reason, it's not making it into the LEVEL_EVENT in the program (and I have quadruple-checked that I have the correct variables/constants in the event). I just upgraded firmware to no avail, and I'm about to tear my hair out. Ideas?

vining

What's the level channel of PROGRAM_VOLUME_FB? You may need to set_virtual_level_count if it's higher than 8 (?). So in an online event handler for the virtual device set a desired count and the call the rebuild_event function to rebuild the level event's event table.

zerodev

It's 21, but I tried to change it to 3 for testing purposes earlier and still got nothing.

vining

I would verify that PROGRAM_VOLUME_FB has the same value in both the module and the main. Also verify your virtual definitions are the same in both. Maybe for th sake of testing remove the vdev structure and use a single vdev and then add some send_string 0's in the events to watch in the diagnostic window.

It you go back to levels above 8 you'll need to set the virtual level count as mentioned before. My memory is a little off and maybe virtuals are only initiated with 1 level. I think it's 8 but right now I really can't remember so just use the set_virtual_level_count anyway and see if that helps. I know in the past I've had to use that on real devices too for both levels and channels and it is a good practice to just do it cuz you never now when another firmware release will break it again.

Spire_Jeff

Also, remember that if the level value you send is the same as the previous level, the level_event will NOT trigger again. This can be a little finicky at times when dealing with modules and multiple masters during a reboot or initial start-up. If the processor gets a level and executes the level event before a touch panel has come online, it can prevent the data from being properly initialized on the touch panel and it won't update until the level value changes.

There are ways to get around this. One would be to save the level value to a variable and when the touch panel comes online, you can update it with the stored value. Another thing you can do is to send the level.value-1, then send the actual level value. But, it seems like you are seeing a level change on one side.

My new line of thinking is the sDevice[2].vdvDevice in the level event. Is the value of this variable set in the define_start section? If it is, I think you might need to look at the rebuild_event() command.

Jeff

zerodev

Interesting. The variable for sDevice[2].vdvDevice is indeed initialized in DEFINE_START. Wondering if that's my issue, though I'm not sure why other, similar level events work properly. I'm also positive that PROGRAM_VOLUME_FB is the same in both because they're both referenced from the same .axi file. The fact that other levels are working is what bothers me most! I'll have to try some of your suggestions...

FYI, I get around the re-triggering issue by resetting the level if it's been triggered. That way there's always fresh feedback if the level gets triggered with the same value as before. Wouldn't think that would be an issue with this particular problem, but I might be wrong.

I did figure out a way around this by defining my touch panels in the module and just sending a level event directly to the bargraph from within the module. This works just fine, but it's not the way the rest of my program functions and I would love to get it all on the same page.

Thanks for the help!

zerodev

Question about the 8 levels: does each level event for each virtual device count towards that maximum? Or is it 8 level.input.levels that are supported? Big difference for me - I definitely have more than 8 level events going right now.

vining

There was a thread recently that screwed my head up on this subject so I'm not sure of anything right now. That was reall devices if I recall so hopefully virtuals are the same and when you define a virtual by default they have limits of 255 channels and 8 levels and that's level channels numbers 1-8 are usable while anything above is comletely invisible to an event table. Possibly if you created an array that's initiated at compile time and have an event table based on that array you may not need to call SVLC (set_virtual_level_count ). Otherwise if you have levels channels above 8 you have to use the SVLC in the online event handler for that virtual device. After you call the SVLC you need to call rebuild_event() to rebuild the event tables that were initialized to the default values but now need to be updated for the new count.

That's my current recollection of virtuals and how I'm currently treat them until I'm notified to the contrary. If I had time I'd almost like to run some tests to confirm my thinking but I don't.