pyscada/PyScada

Various variable value class with the same key

clavay opened this issue · 4 comments

clavay commented

The value class key should be unique.
Keep only one value for :

  • float 32, 48, 64
  • int 8, 16, 32, 48, 64
  • uint 8, 16, 32, 48 (missing), 64
  • boolean

Should we add other value classes ?

@trombastic : what is unixtime[i or f][32 or 64] value class for ?

PyScada/pyscada/models.py

Lines 1233 to 1260 in 79b98d0

value_class_choices = (
("FLOAT32", "REAL (FLOAT32)"),
("FLOAT32", "SINGLE (FLOAT32)"),
("FLOAT32", "FLOAT32"),
("UNIXTIMEF32", "UNIXTIMEF32"),
("FLOAT64", "LREAL (FLOAT64)"),
("FLOAT64", "FLOAT (FLOAT64)"),
("FLOAT64", "DOUBLE (FLOAT64)"),
("FLOAT64", "FLOAT64"),
("UNIXTIMEF64", "UNIXTIMEF64"),
("FLOAT48", "FLOAT48"),
("INT64", "INT64"),
("UINT64", "UINT64"),
("UNIXTIMEI64", "UNIXTIMEI64"),
("INT48", "INT48"),
("UNIXTIMEI32", "UNIXTIMEI32"),
("INT32", "INT32"),
("UINT32", "DWORD (UINT32)"),
("UINT32", "UINT32"),
("INT16", "INT (INT16)"),
("INT16", "INT16"),
("UINT16", "WORD (UINT16)"),
("UINT16", "UINT (UINT16)"),
("UINT16", "UINT16"),
("INT8", "INT8"),
("UINT8", "UINT8"),
("BOOLEAN", "BOOL (BOOLEAN)"),
("BOOLEAN", "BOOLEAN"),

trombastic commented

The value class key should be unique.
proberbly, this was added because in many systems the data types have different names, this should help the user to choose the right one, but i agree with you that it adds space for confusion and should therefore be changed.

the UINT64 is missing because there is no way to store it in some of the databases, it is always is casted to IN64, this may have changed in the meantime

what is unixtime[i or f][32 or 64] value class for
storing a unixtimestamp as int32, int64 or float32, float64 in the recoded data database, so the user can decide if he want's sub second resolution or more range

clavay commented

The value class key should be unique.

proberbly, this was added because in many systems the data types have different names, this should help the user to choose the right one, but i agree with you that it adds space for confusion and should therefore be changed.

but when you don't choose the first key in the list, after saving the admin variable page it will display the first element matching the key.
For example choosing ("FLOAT64", "FLOAT64") will always display after saving ("FLOAT64", "LREAL (FLOAT64)").
It may be confusing for the user.

the UINT64 is missing because there is no way to store it in some of the databases, it is always is casted to IN64, this may have changed in the meantime

One option, if it is really needed, is to store the value using two PositiveBigIntegerField. What do you think ?
It could be possible to do when I will push the commits allowing to specify a custom data source (allowing to use a specific django model with specific read/write functions)

clavay commented

In order to have a unique key, what do you think to change value_class_choices by

    value_class_choices = (
        ("FLOAT32", "REAL, SINGLE or FLOAT32"),
        ("UNIXTIMEF32", "UNIXTIMEF32"),
        ("FLOAT64", "LREAL, FLOAT, DOUBLE or FLOAT64"),
        ("UNIXTIMEF64", "UNIXTIMEF64"),
        ("FLOAT48", "FLOAT48"),
        ("INT64", "INT64"),
        ("UINT64", "UINT64"),
        ("UNIXTIMEI64", "UNIXTIMEI64"),
        ("INT48", "INT48"),
        ("UNIXTIMEI32", "UNIXTIMEI32"),
        ("INT32", "INT32"),
        ("UINT32", "DWORD or UINT32"),
        ("INT16", "INT or INT16"),
        ("UINT16", "WORD UINT or UINT16"),
        ("INT8", "INT8"),
        ("UINT8", "UINT8"),
        ("BOOLEAN", "BOOL or BOOLEAN"),
    )
trombastic commented

this is a good idea