Spurious reflex packets

[smoothquark]

I seem to have some reflex packets which refuse to be deleted! There is a bug in Cortex which does not turn off any pre-programmed reflexes, but thanks to Karam, I managed to get it working. However, I now have about 16 QBI modules, and decided that I will erase all reflex programming for now until the bug is ironed out. However, I have 3 QBI modules with reflex programmed into button 2 which refuse to be deleted. The packets are all the same:

Pkt 1= 0EE23002FF10FFFF102048003E0301
Pkt 2= 0EE23002FF10FFFF102048003E0302

How do I delete these? A "factory reset" does not not either...

[Karam]

When you say these packets still exist, where are you seeing them? Cortex itself maintains copies of Reflex packets even if they are disabled on the module.

When Cortex deletes a Reflex the Reflex code on the module itself is not 'deleted'. All that happens is that the vectors to that code are 'nulled' (FFFF) and any associated Reflex gating flags such as UDR enable are disabled. So its a bit like what happens to deleted files on a computer disk. When new Reflexes are created they might simply overwrite old code.

When Cortex performs a node profile analysis it only displays any Reflex code which has a non null vector pointing to it. So if you are still seeing such packets in the node profiler then it suggests the vectors have not been nulled. But if you reset the module to its factory defaults these vectors should also be nulled (but Reflex code itself not wiped) and as far as I'm aware there is no bug which prevents that.

In a sense it deosn't really matter what is held in the module's Reflex code area if there is nothing pointing to it. But if you want to be pedantic you can wipe this (where wipe means value of FF). Reflex code is generally (and certainly so for QBIs) started at EEprom address 0100 onwards. So if you want to actually wipe the code out then you can visit the node profile utility select the module address then select the Master EEprom tab and then from Node drop down menu select Clear node memory with FF.. After which you will be asked for a range to clear for which you should use 0100 as start and probably 01FF is sufficient for end.

If you wipe between 0000 and 01FF then you will also clear out other saved parameters and the module will end up in the factory default state but also with cleared out Reflex memory.

[smoothquark]

Thanks Karam. I tried the factory reset again, and this seems to have cleared the packets. I don't understand why clearing reflex packets from within "reflex tools" or the QBI reflex menu worked? Looks like I am heading towards a DFP!

[chris_j_hunter]

>about 16 QBI modules ...

'tis a goodly number - could I ask how they're used - lights on/off & dim up/down seems likely, but ... ... and have you found new uses have arisen as time's gone-by, so their programming's evolved since they were installed ???

[smoothquark]

Had to rewire the house, so all lights home run to the "hub" in the garage with a number of QRI002 for lights and QRH001 for electric UFH + electric towel radiator elements etc. The QBIs replace standard light switches and bedside light switches. A real pain to try and reflex program them. The automated version does not sort out the reflex programming of LEDs, and changing reflex button functions to make them more intuitive is a pain as well, never mind the fact the reflex in the buttons have to be disabled using a macro if there isn't a DFP on the network. Still working on it - there must be an easier way of just going through the database and programming reflex from there.

[chris_j_hunter]

thanks - did you re-position the switches, for better convenience, or just substitute ?

interesting about the LEDs - we've in-mind to use them to also allow easy-finding of the buttons in the dark, so could be important they are suitably programmed / controlled !

database approach might be good - perhaps, ideally, one big table that could be pasted-in from a spreadsheet application, for easy comparison of hex numbers & maybe even some measure of auto-calculating them ... (?)

[Karam]

never mind the fact the reflex in the buttons have to be disabled using a macro if there isn't a DFP on the network.

Sorry that its taken so long but this particular aspect has now been corrected in Cortex V24. An update is available.

The Autoreflex programming tries to emulate in a very basic way what is programmed in the Cortex database eg. if a button is connected to operate a particular light or set of lights in the Cortex database then the Autoreflex programming will in all likelihood make that button simply toggle that light/s. The idea is to provide an automatically programmed set of Reflexes which provide the user with 'emergency' controls rather than try to do all the subtle things that can be done at a Cortex level. Obviously more intricate or different Reflex functions can be programmed but these need to done manually, best through the Cortex Reflex programming utility. I'm not saying its easy to understand but doing the Reflex programming via Cortex means you have a structure which tracks where all the bits of code go into the various module memories and in general can provide more abstracted referencing.

We maybe need to look again at how you are connecting the buttons (i.e. the desired functionality) to be able to figure out a) how better to guide the Reflex programming, b) whether there is anything generic we could do to improve the Autoreflex tool in this context. So if you'd like to contact us with details of your present issues (beyond the above bug fix) then we can try and help

[smoothquark]

No, not a major problem. It would be nice if the auto reflex programming tool were to program the LEDs as well, as a visual indicator. Interestingly, found another "bug" - for some reason, some of my modules within the tree in Cortex where not in the correct sort order. So, I moved them around to get the right order, and ALL the relevant button code got erased! Not sure why - I thought the "instructions" were stored using the module network IDs, so should not be a problem. When I get some time, I will see if I can replicate that, using my backup files. Would be an interesting experiment!