Something to take into account while developing a project and using alarms on Visilogic.

[Fernando Castro]

Today I found out a funny thing... those silly ones that make you want to bang your head against the wall.
Let's name the development project A and the production project B

So, I was adding a new feature to project A (which in general has some experimental things). when I was happy with the result, I exported a subroutine packing all related to this new feature in it, to project B.
However, this case project B had one of the MIs used in that subroutine, previously assigned to an alarms group.

 

This was not a big deal since that alarm group was declared at some point in time, but since I never added anything at all, I decided to delete Group 5 from the alarms.
Did a quick search of MI166 to make sure that is not being used in any other place and proceeded with the changes, as usual, compile, download and test.

So, after deleting and testing happened that I wasn't able to use MI166, it was always overriding whatever value I stored on it to a 0 value.
I felt dumb after investing a lot of time in searching all vector-related functions (I believed that I may have been storing that 0 value by accident while using some vector).
And then I remember the alarm group... It couldn't be right. why that should be interfering with the rest of the code if I already had it deleted?

So, I decided to create it again, and it auto-populated with the same MIs and MBs, I re-assigned new MIs and MBs to it:

 

And only then I was able to properly use MI166.

I know that it would have been faster just to choose another MI instead of MI166, but I needed to get to the bottom of this Mystery.

So, if someone gets one of these rebel registers that refuses to cooperate, it may be worth it to take a look at the alarms.

 

[Flex727]

Good info, Fernando! Thanks for taking the time and trouble to document this properly.