function to match a native TIA portal export to a DB layout specification string #533
Conversation
snap7/util/db.py
Outdated
| with open(txt_path, "r") as file: | ||
| db_specification = "" | ||
|
|
||
| valid_list = ["BOOL", "DWORD", "INT", "DINT", "CHAR", "STRING", "DATE_AND_TIME", "TIME_OF_DAY", "REAL", "BYTE"] |
There was a problem hiding this comment.
nit: If you replace the list with a set, the operation x in s will be faster
| parsed_line = line.split("\t") | ||
|
|
||
| var_name = parsed_line[0] | ||
| var_type = parsed_line[1].upper() |
There was a problem hiding this comment.
Is there a reason why the literals in valid_names are uppercase? If they were lowercase, you wouldn't need to call .upper() for every line
There was a problem hiding this comment.
valid_names are list a copied from another part of this repo.
TIA portal exports variabiles types with the first letter in uppercase anyway
|
|
||
| var_name = parsed_line[0] | ||
| var_type = parsed_line[1].upper() | ||
| var_offset = parsed_line[2] |
There was a problem hiding this comment.
I don't know what the export file format looks like. Can there be empty lines or comments in it? This could cause an exception, something like 'list index out of range'
There was a problem hiding this comment.
as far as I know: no.
this is an example of tia export:
PRESENT Bool 3968.0 false --- False True True True False PIECE PRESENT SCRAP Bool 3968.1 false --- False True True True False PIECE SCRAP READY Bool 3968.2 false --- False True True True False PIECE READY DRY_TEST Bool 3968.3 false --- False True True True False DRY TEST MOVING Bool 3968.4 false --- False True True True False PIECE MOVING SCANNED Bool 3968.5 false --- False True True True False QR_NOK Bool 3968.6 false --- False True True True False QR CODE NOT OK LONG_PROFILE Bool 3968.7 false --- False True True True False VB_ACK Bool 3969.0 false --- False True True True False
snap7/util/db.py
Outdated
| var_name = var_name + to_add | ||
| var_names.append(var_name) | ||
|
|
||
| if var_type: |
There was a problem hiding this comment.
If var_type is an empty string, then var_type in valid_list is will be False. So there is no point to check var_type
| var_offset = parsed_line[2] | ||
|
|
||
| to_add = "_0" | ||
| for name in reversed(var_names): |
There was a problem hiding this comment.
I think using a dictionary, where the key is var_name and the value is a counter, would be cleaner and more efficient than using a list. Something like this:
var_names: dict[str, int] = {}
to_add = var_names.setdefault(var_name, 0)
var_names[var_name] += 1
var_name = f'{var_name}_{to_add}'And you won’t need an inner loop in this case.
snap7/util/db.py
Outdated
| if var_type: | ||
| if var_type in valid_list: | ||
| new_line = var_offset + "\t" + var_name + "\t" + var_type | ||
| db_specification = db_specification + "\n" + new_line |
There was a problem hiding this comment.
nit: Perhaps appending "new_line" to a list and then using join() is more efficient. But I’m not sure it makes a significant difference
There was a problem hiding this comment.
I doubt so, especially considering this function is meant to be run only one time for db....
|
@Novecento99 Nice work |
Hi,
as anticipated I was working on a function that could ingest a native TIA portal export of a non-optimized db to generate a string compatible with the DB class layout_specification
It also manage names duplicates by adding a suffix "_X" at the end of the variables, where "X" is a progressive numeration.