Multi vis look up table order

[msmith_ncl]

I have a multi-vis block created with 6 lookup tables, 1 has 13 options, 1 has 4 options, the other 4 lookups only have 2 options each.  I have created all vis states and the linked lookups and they seem to be working ok at the start but then some of the vis states do not display until I change more than 1 lookup and then wont go back to the previous state.  My question is re the big table for all different combinations of lookups, does the order of these lookups left to right make any difference?  I have tried to adjust and it does seem to make some difference but cannot work out what happens when I re order these and what order they need to be in, can anyone please advise?

[Libbya]

Post the block.  

[msmith_ncl]

Block attached here, you will see when selecting some of the lookups, the visibility doesn't change until i change a different lookup, it then updates for both, any help is appreciated.

[Libbya]

Your block uses the initial method I posted for visibility switching using single/double lookups.  It works, but I have learned some ways since then to both simplify it and make it a bit easier to avoid mistakes.  Instead of a linear parameter for storing each single lookup selection value, I now use point parameters.  You can use the X and Y values of a point parameter independently on a lookup table, so a single point parameter can be used to store the selection values of two different single lookups (one stored in X and the other stored in Y).  You also do not need to add the move actions and little circles as the parameter will still function in the lookups without those.  Another significant change I made in my process was in the naming of the visibility states and the lookup row names.  I now use the values for the selection lookups, (e.g. 1-1-1-1, 1-1-1-2, 1-1-1-3, etc...).  I find that having that simple naming convention makes it easier to construct the block, reduces typographical errors, and makes finding those errors a lot easier.  

For the switching to work immediately upon insertion, the as-drawn values of the input/storage parameters must match a row on the double lookup table and that row must match the visibility state that is topmost on the visibility state dialog list. 

To answer your question, the order of the input properties on the double lookup table should not make any difference in the operation of the block if it is assembled correctly.  It might make a difference if the as-drawn state of the block does not match the topmost visibility state but I haven't confirmed that.   

The following screencast is just my initial look at the block, but might be helpful.   

[msmith_ncl]

Thanks for looking, 1 more question, not all combinations are technically possible, I have included any combination that cannot be done in the bridge lookup and assigned a possible vis state.  For example, some lock types are fail safe only, I have made that lookup not visible when using 1 of these locks but if this is already set to fail secure on a different lock before selecting a fail safe lock, the attribute I have using a field will remain fail secure with the block displaying fail safe.  Is there any way I can control this?  I will be exporting these attributes to a CSV for import top excel.  Do i need to have all possible combinations in the bridge lookup?  I tried to remove a few unusable ones but that stopped working.

Thanks

[msmith_ncl]

I have reworked this now to use a block table to control visibility, all working much better than before.

Thanks

[Libbya]

Block properties table is functionally the same as the lookups aside from the method of selection.  If you want the nested pulldown menus, then use the BP, if you want individual selection grips then use the lookups.

If there are some combinations that are not ever used then it is possible to avoid those with either method.  With a BP table, you just don't create the row.  With lookups, you can have contextual lookups that are visible for each of the visibility states that would lead to the unused state and just don't have the final option that would lead to that listed on the contextual lookup.  

[msmith_ncl]

Please can you explain contextual lookups more, I have the block working perfect with a table but would prefer lookups as there are 5 different things that can change and I prefer people to be able to just choose the one that's changing instead of running through the full table options each time, still having problems with lookups where the vis state sometimes doesn't update until I change a 2nd lookup and then the 2nd device I changed is wrong and wont go back to how I need it.  I suspect this is because of the unused combinations.

Thanks

[Libbya]

Can you post the block in its current lookup form and give details about which states do not switch properly?

What I mean by a contextual lookup is one that is visible only for one or maybe a few select states.  That lookup would not have the options listed to reach states that should not be used.  If you post your block with details about which states you do not want to be selected I will post up an example.  

[msmith_ncl]

The block I posted before has these problems, its difficult to explain but I will try.

The STRIKE lock is a strange one, this lock has 2 choices for exit type, BUTTON or PIR, if using a BUTTON, the STRIKE lock must be FAIL SAFE, if using a PIR, the lock can be FAIL SAFE or FAIL SECURE.  This is the only lock that has a choice for exit type, all other locks are pre determined exit type.

MAG is a lock that can only be FAIL SAFE, I made the lookup for FAIL SAFE/FAIL SECURE not visible when MAG selected and this seems to work ok.

There are some lock types that don't have any other devices, no door contacts, no exit type, SPEELANE, TURNSTILE, BARRIER and EXIT READER, these have no other equipment associated so no other lookups when selected.

The block seems to be working ok for the most parts then for some reason when I change one of the lookups it doesn't change the visibility for that lookup until I change a different lookup, it then changes both visibilities at the same time but I needed to make a 2nd change to get the first one to work and now the 2nd lookup wont change back to the state I wanted when I changed the first one.

All is working perfect using a table but I would prefer single changes on each device over running through the table options each time.  Thanks.

[Julio_Soto]

what software do you use for your videos?

[Libbya]

@msmith_ncl The initial block you posted contains the errors I demonstrate in the video.  I did not save the block after demonstrating those issues.  It is also set with lookup property names and visibility state names that are confusing to me and a fair amount of work to understand as I stated in my post with the prior video.  I imagine it would take me 10+ minutes just to fix the known issues and then examine the block in order to even get started on the specifics you outline.  That time burden is more appropriately placed on you than it is on me.  If you have a block that is updated in the ways I describe in that post and accompanying video, then I will assist with further diagnosis of issues.  If instead you want to post a simplified block in order for me to relate the concept of contextual lookups, I am willing to do it that way also.  I'm not going to start over with that originally posted block, though.  

@Julio_Soto I use Autodesk Screencast.  It is free and simple to use.  

[msmith_ncl]

Thanks, I have decided to stick with the block table, the block has grown quite a lot since the last one I uploaded with many more combinations that would complicate it even more.  I decided it not worth all the time to engineer and we will use the one with the block table, this works perfect and is easy to add / remove new states.  Thanks again for your help, much appreciated.

[Julio_Soto]

I didn't know that existed, thanks!

[GD.ON]

Hi there!

I have found your post and it seems like you're the expert for a multivisibility state blocks.

I'm trying to put things in order in the custom properties, but despite my efforts I cannot see  main parameters in the Parameter Manager, so I cannot set up correct order. Would you mind to take a look please?

[hwalker]

@GD.ON Look at the image below

[GD.ON]

Thanks for quick reply.

I cannot see lookup parameter here. "Height_Range_" is related to hidden dimension for multivisibility state.

Even setting it up as visible with no.1 order, there's no change to the custom properties view...

[hwalker]

Lookup parameters don't show up in the parameter manager. They always stick to the "number" where you put them.

And since you put those two lookup parameters in last, that is where they will stay.

[GD.ON]

... ah well...

 Thanks.