Table lookup not seeing correct values

[Thomas.Long]

My table lookup is doing something interesting. Let me start off by saying this is supposed to be constrained to certain sizes (it's a block that represents structural channels, so all of the sizes are predefined) so I want it to be set so that it has to match the values in a given table. Now the issue with this is that it keeps saying that it doesn't match values in the table and errors out.

My first thought was that there was a difference in values that was too small to be represented in the level of precision I was showing; however, I tried telling it to add a new row and that should have added in all the correct values for the current layout, but even after doing that it said it didn't match any rows. 

Can anyone tell me why it's doing this? Also, the stretch for the W flange beam web doesn't seem to function correctly (it keeps spitting out very large W flange beam webs even though the value for the constraints is correct). If anyone could figure this out I'd be much obliged. 

Thank you

[Libbya]

You have a block properties, not lookup table (confusing title to thread).  You have a blank default value for the user parameter (with blank name first row on table).  You need to have change the default string value for the user parameter so that it matches the row that also matches all of the other as-drawn parameter values on the table.

[MMcCall402]

Yea, if you're using a block table and restricting it only to values that match the table then the current entities in the block need to completely match one of the rows in the table.

[Libbya]

I looked more in-depth at your block.  You had two issues messing up the block properties table.  One was that one of the parameters did not match any of the row values.  You only see that after increasing the precision.  The other issue is what I mentioned previously with the lack of default value in the blank user parameter.  Here's a screencast showing my diagnostic process and eliminating the discrepancies with the block properties table.  

[Thomas.Long]

Thank you, I'll take a look at the video today. Yeah I'm having a bit of difficulty controlling this block. I find it strange the exact level of precision they're requiring here. Is there any way to set a tolerance? It seems odd that it has to be exact down to millionths of an inch when we clearly won't care about any of that.

[Libbya]

The values must match exactly.  There is no tolerance.  You can define ranges in lookup tables but not in block properties tables.  Regardless, drawing your parameters initially to exact values is as easy as typing in the value.  Fixing it afterward is also easy as I show.  

[Thomas.Long]

Yeah I figured out why it was refusing to align exactly even when I typed the values in directly. Because it was constrained from the middle, when I tried to shift one edge up it was moving the entire thing. I basically had to delete my web lines out and set up a miniature line along the edge that I could constrain to the center in order to constrain it all correctly.

Out of curiosity did anyone figure out why my webs weren't constraining correctly for the IBeam visibility?

[Libbya]

I don't think there is any reason to have any constraints in this block.  Any constraints are just redundant at best and often are the cause of issues.  The block geometry is already controlled via the dynamic parameters/actions and the block properties table.  I think that the interaction of the constraints and the dynamic parameters is probably what is causing the issue.  Delete all of the constraints.  

[Thomas.Long]

While true, I do need to keep the web of the IBeam locked to a give distance from the center not contained in my parameters. I could potentially do as you suggested but it would entail reworking the entire way the block works in order to ensure that the centers of all the lines keep at the same point as each other. I'll try saving a copy and seeing which works better. 

Thank you.

[Libbya]

If you need an adjusted and specific location for linework depending on the block selection, then add an appropriate gripless parameter, add appropriate move/stretch actions, and add that parameter and the appropriate values to the block properties table.  

[Thomas.Long]

Ok, I tried what you said and it gave me the same error. I noticed something weird though. When I told it to check the block properties table it said it error'd and asked if I wanted to add a row that matched. I said ok, even though the values it added exactly matched another row (I took it down to 8 decimal places, everything matches.)

I added the same name in the unnamed column that's basically just the label for each state in the lookup table and it error'd again when I tried to close saying it still didn't match. I deleted the name from the label column I had just added and it didn't throw the error anymore. For some reason, I guess the label column for the block table is a parameter that it's not recognizing as matching?

[Libbya]

You are using the term 'lookup table' incorrectly.  You do not have any lookup parameters or lookup tables in this block.  You have a block properties table.  Lookups behave similarly to block properties tables but they are not the same thing and have some important functional differences.  

Did you change the default parameter distance for the incorrect parameter?  

Please post the updated block with every step except having the block properties add a row.  

[Libbya]

Also, in the screencast, you might note that I added a second user parameter with name (size), copied all of the values from your unnamed parameter, moved it to the appropriate column position, and deleted the prior user parameter.  I did that because I found that the prior parameter had issues and would not allow me to edit the name or default value.  Did you follow those same steps?

[Thomas.Long]

Here is the updated block. I deleted all constraints in all visibilities and traded out the singular constraint the web thickness on the IBeam visibility to a pair of distance parameters from the midpoint to each web line with half the distance I'm looking for (coupled with some gripless stretches). The parameters should all be correct, but for some reason it's the label column that the block table automatically generates (the one without a name at the top) that is causing issues it looks like. 

I tried deleting the name from what is supposed to be the active row and it works just fine, but when I add the label in it still causes issues.

[Thomas.Long]

Sorry I haven't gotten a chance to view the video and won't be able to until lunch.  The video was blocked by my workplace so I'm going to need to use my phone for that.

[Libbya]

Ok, as I mentioned in my last post, there is something wrong with your unnamed user parameter (corrupted?).  It does not allow correct editing.  Create a new user parameter with type = string.  I'd recommend giving it a name this time (size?).  The topmost visibility state listed in the visibility dialog is channel.  The row that matches that visibility state and the other as-drawn parameter values in the block properties table is MC18x42.7.  Open parameters manager and find your new user parameter.  Paste that size name into the expression field.  When your visibility pulldown is on 'channel' the block properties table will not have an error.  

[Libbya]

I would mention that you have A LOT of extra linework in your block that is not visible in any visibility state.  Maybe that is vestigial from having each size drawn instead of modified by the parameters/actions/table.  When you no longer need that extra linework, your block size will decrease if you delete it.  

Also note that when in block editor, if you switch the visibility pulldown to ibeam, the block properties will show an error again because the user parameter default value does not match that visibility state.  That is not a concern as long as the error goes away when switched to channel within block editor.  Channel is the topmost state in the visibility dialog and so is the state that will be active when the block is inserted.  

[Thomas.Long]

Ok I think I understand what is going on now. I didn't create that parameter. I assumed that was something that was just in every block table. It was already in there when I opened the new block table. I assumed that was meant for the label field for the block so that when we did a grip edit it would show that.  I'll try to figure out how to create a string parameter lol

[Libbya · Accepted solution]

You can create the parameter from within the block properties table or from Parameters Manager.  You can switch the Type or default values after creation within Parameters Manager.  Right-click on the header will allow you to select what rows are displayed in Parameters Manager.  It seems that Type is not displayed by default.

[Thomas.Long]

Yeah I just realized that, was going through trying to figure out how to change it and found my way into the columns area for the parameters manager and added in type. The grip isn't displaying but the entire table hasn't been filled out yet, but other than that the table seems to be working. I'll check in on it after lunch and I'll watch your video.