question

Property tables are intended to be a starting point that allows you to programmatically update object properties. By pressing the SQL button in the property table UI, you can see the query that corresponds to that property table. Then, you can use that query (specifically the WHERE clause) to create your own SQL UPDATE query. For example, the query below should do what you are intending, i.e. set the MaxSpeed property on all task executers based on a lookup from the tableSpeeds table.

double dInchesPerSecond = Table("tableSpeeds")["ANT_SPEED""]["VALUE"];
Table.query("UPDATE Objects() SET MaxSpeed = $1 WHERE 'TaskExecuter' IN Classes", dInchesPerSecond);

You could also do an inner join, to set multiple different values based on different entries in the tableSpeeds table. You could add a "Group" column to your tableSpeeds table, to distinguish which objects should have their speeds set to what values.

Then you could execute a query like the following:

Table.query("UPDATE Objects() INNER JOIN tableSpeeds ON tableSpeeds.GROUP IN Groups SET MaxSpeed = tableSpeeds.VALUE");

This goes through the 'Objects()' table, i.e. all objects in the model, then matches the object with the row in tableSpeeds that has the group that the object is a member of, then sets the MaxSpeed property of that object to the value in tableSpeed's VALUE column.

Also, as of 21.1, you can integrate property tables directly into your UPDATE query:

double dInchesPerSecond = Table("tableSpeeds")["ANT_SPEED""]["VALUE"];
Table.query("UPDATE TravelProperties1 SET MaxSpeed = $1", dInchesPerSecond);

Also as of 21.1, property tables will be properly integrated into the Table class. So you can essentially do your for loop.

double dInchesPerSecond = Table("tableSpeeds")["ANT_SPEED""]["VALUE"]; 
Table propTable = Table("TravelProperties1");

for (int iANT = 1; iANT <=  propTable.numRows; iANT ++){
    propTable[iANT][2] = dInchesPerSecond; 
}

Although I personally feel like using Table.query() is cleaner. Property tables are built on, and integrate deeply with, FlexSim's SQL engine. So, when you're interacting with property tables, it's useful to shift your paradigm to thinking from a SQL perspective. If you can do that, and grasp some basic SQL concepts, both updating and querying data becomes pretty easy, and avoids having to write a ton of for loops.

And, since the cat is out of the bag, yes, we're working on a "templates" feature. When you create an "instance" of a template, by default the instance will "inherit" most properties from its template, so if you change them on the template, those changes will automatically propagate to all instances. However, you can override any and all properties on each instance as needed, include things like length, or whatever you want. Thus, what is inherited and what is overridden is defined by you the user. This feature is what the conveyor types should have been, but were really badly designed.