sicli - parameter writing to RAM/Flash

[Jusufs]

Rpi4 raspbian bullseye 64bit Failure on write only to RAM, regardless of 1550 state.

(venv) pi@rpi64:~/openstuder-examples-python/cli $ ./sicli user:pw@localhost connected to 192.168.100.236 running gateway version 0.3.2 with access level QUALIFIED_SERVICE_PERSONNEL localhost ~ write xcom.xt1.1107 2 On 1550 flash write enabled set to Yes, it changes the value to 2.

What happens if 1550 is set to No please ? Some parameters like 6062 are on openstuder temporary changeable without writing to flash.

I'm missing the information about attribute from all temporary changeable parameters. Are some changes only to RAM verbosed if system components are tightened please ?

[cm0x4D]

It is a bug on the gateway side. Currently we only did write permanently (default). We will try to fix that for the next version.

[cm0x4D]

There is a reason we only used flash parameters and never RAM based ones.

According to the Modbus protocol specification we can not read back the values written to RAM (At least I did not find such function), so even if we would write something to RAM, we would read back a different value from flash which is not ideal. Additionally after a system restart the RAM parameters are gone, so this was rather pointless for our use cases.

Even after the fix, if you write a 2 to RAM and read back the same parameter to see if it has worked, you would still get the value from flash (16 I guess).

I do not know how many write cycles are possible to the flash of the Xtender, but as long as those parameters do not change to often, it should be ok. With the new release of the gateway software you will be able to write to the RAM, but you need to know that you will read back always the value in flash.

[Jusufs]

Thanks for answer, but I disagree according using write only to RAM question. Writing can be changed from dynamically external PLC control and control Xtdender behavior. E.g. If control system dynamically changes par 6062, then charging from AC In/Out can be stopped without switching of transfer relay and vice versa. Or dynamically change of transfer, inverter, charger etc. allowed can be external done from control algorithm.

I'm missing information if some limitations exists, if the xtender system is working under load. Maybe it isn't a problem and the change is taken on next internal control cycle.

But in xcom485i package (which doesn't use sigatewayd) is this possible or ? https://github.com/studer-innotec/xcom485i/blob/master/examples/ex_write_param.py Maybe same approach can be used on cli write commands, but if it is a bug or non finished work, it can't be done. But with xcom485i package isn't some describtion e.g. ModbusTlg=14 for xt1 like xcom.xt1.1107 'Maximum current of AC source" "Aac"

def write_parameter(self, slave_id, address, value):
    """
     Write a parameter value into a targeted device.

    Note
    -----
    All parameters accessible from *RCC* can also be accessed with the *Modbus* protocol.\n
    In the *Xtender* system, it is possible to write a value in Flash (and RAM) or in RAM
    only.\n
    To distinguish between both, we use a different register address offset as explained below:\n
    - write value into FLASH and RAM  : offset is 0    (WRITE_PARAM_FLASH_RAM)\n
    - write value into RAM only       : offset is 6000 (WRITE_PARAM_RAM_ONLY)\n

    Parameters
    ----------
    slave_id
        Slave identifier number (targeted device)
    address
        Register starting address, see *Studer Modbus RTU Appendix* for the complete list of accessible
        register per device
    value
        The value to write

    Returns
    -------
    int
        Quantity of written registers (must be 2)

P.S. For me the simplest way is to set always Flash OFF (1550=0) on each start of external monitoring/controlling PLC. I propose that each modification of 1xxx, 6xxx parameters via PLC control should be succesfully applied only in RAM.

Normally the state of 1550 in a system without xcom-can adapter is memorised. On my system also on last FW 684 with xcom-can 1550 becomes every "hard" start of xtender system true value. I don't received a answer from Studer support, why this HW combination doesn't memorise state of 1550.

Return information of parameter change can not be read out - OK, no problem. I can observe behavior change in some cases.