Databases not matching

I had to replace a faulty DLT today and no big issue swapped it out and fired up toolkit. I did a reinstall and for whatever reason TK didn't like it and hung. Rebooted and installed the DLT unit the old fashion way.

Anyway when I looked at the database in the summary mode the database names didn't match the key GA names.

I noticed that the block assignment were completely scrambled, that is the GA's were either not in the order matching the keypad convention or GA's that were not even in the 8 GA's assigned to the keypad!

I changed one GA on another keypad that was working fine and then checked the database against the keypad GA's assignment and it didn't match, checked the block assignment and sure enough the block assignment was all over the place.

Then I check keypads that have not been programmed for years and some were perfect ie the summary database, input database, keypad GA assignment and block assignment all match correctly. However other keypads that had not been programmed for years had their block assignment GA scrambled and therefore the summary and input databases do not match.

When I say scramble I mean not in the correct order, or the correct GA pertaining to the keypad GA programming

I have never touched the block GA assignment or order. About half of the are scrambled.

I have reassigned one of the keypad blocks to match the keypad GA, saved it to the database and keypad and all is well.....all databases match.

Any ideas what has gone wrong?

Regards,

Fleetz

 

Blocks and Groups

Hi Fleetz,

It may be a surprise to you but maintaining a nice straight diagonal on the Blocks tab has never been a goal of engineers at Clipsal. Blocks idea is simply a means of linking groups to keys so you can link multiple groups to a single key and multiple keys to a single group.

At some point long ago it has even been considered not to expose blocks on GUIs at all for the reason of unnecessary complexity and risk of confusing users, but eventually the idea of putting blocks under the Advanced settings and giving users access to them won because this feature is powerful and provides extra flexibility for the configuration of group/key associations and indicators.

Because of the inherrent complexity of the Blocks tab, a simple view has been added at the top of the input unit GUIs, which manipulates blocks under the hood. You can see this if you open the Blocks tab and select a few groups at the top half of the GUI. The simple view at the top makes it unnecessary for the user to change anything directly on the Blocks tab in most cases. But everything has a price. In this case the visual "niceness" of blocks to keys associations has been sacrificed in order to allow people select any groups for any keys in the simple view and easily change this configuration later with as few mouse clicks as possible.

So the straight answer to your question is - nothing has gone wrong. This is how things are meant to work in case with blocks. Ticks on the Blocks tab go out of order when you change groups in the simple view. The more you fiddle with groups in the simple view the more scrambled becomes the Blocks tab. However the way Blocks tab looks does not affect how input unit works.

Now to why you see groups appearing in a wrong order in the summary view. There is a direct dependency between the order of groups on the Blocks tab and groups appearing in the summary view, i.e. what you see in the summary view has been loaded from blocks in the order blocks go from 1 to 8, not in the order keys go! This was done so that groups would be loaded from units quicker to show what groups each unit uses. If you need more accurate information please use the Input view. On this view Toolkit loads extra information from units, which allows it to display groups in the order of keys.

Hope this helps,
George

 

Hi George,

Thanks for the excellent explaination of how blocks work with respect to summary and input databases view.

What is doing my head in is why there are GA's not associated with a keypad in the block assignment. I have as I said in my post I have never touched the blocks. I am seeing GA's in the blocks and saying WTF is that doing there. Some keypads are perfect everything matches then others just don't make any sense.

I have reprogrammed one of the keypads so the block GA's now match summary and input databases save it and all is fine.

I have always operated in the summary database view and never noticed before the GA names not reflect what changes I made to the keypad's key assignment.

So if I have it correct if I wanted to have key and block to match and hence summary and input databases to match also then I need to edit them separately?

Given I only use the summary view I am still scratching my head why they are so far out of whack and have GA's that have non associated key assigned GA's in the block? And not on all only on some.

I will have a closer look armed with your excellent summary and see if I can make sense of what I am seeing.....thanks very much for taking the time to clarify how they work.

Regards,

Ian

 

Hi Ian,

Groups on the Blocks tab not associated with any keys usually appear after you change some key to use the Unused group after it had some other group associated with it. In this case the old group remains on the Blocks tab but its block is not linked to any keys. Perhaps this is what happened, i.e. you opened the unit GUI at some stage to select different groups?

Re summary view. It is good for what it does: shows what groups are there configured in the unit, but you can't trust it beyond that. Summary view is for all unit types, and because of that it has to be generic, i.e. we have to somehow show information which is common for input, output and all other unit types. So we simply show Group 1, Group 2, etc columns, which don't mean Key 1 or Channel 1. Please use the Input and Output views. They have been designed to address axactly that issue you're having now, and they have Key and Channel columns.

Regards,
George

 

Thanks George...... I was blind and now I can see.

Regards,

Ian