@thangleiter There is a logical error in add_parameter if bind_to_instrument is False. I am however curious of you use case for using add_parameter if you don't want to bind to the instrument? Why not simply create the Parameter with DelegateParameter("name", ...) for that use case? The only thing add_parameter really does is to create the parameter with the supplied args and then registers it on the instrument.

Hi @jenshnielsen, in the end it's not a crucial issue. It just came up as I was updating the TimeTagger driver to use the preferred pattern for adding parameters of using add_parameter and assigning the return value. That driver has some hacky helper parameters that don't need to be snapshotted or anything:
https://github.com/QCoDeS/Qcodes_contrib_drivers/blob/438417c01137b5a87adc0c5b67680e8fa09703f5/src/qcodes_contrib_drivers/drivers/SwabianInstruments/Swabian_Instruments_Time_Tagger.py#L297-L305

Obvioiusly, I could just not use add_parameter, but I think it's ill-advised to proliferate both the param = Parameter(...) and param = self.add_parameter(...) patterns now that there's finally a solution that combines the two patterns that existed alongside previously.

@thangleiter Thanks for the explanation.

If you want to avoid snapshotting I would recommend passing snapshot_exclude=True to add_parameter

Honestly, I never planned for the use case where someone would do `self.foo = self.add_parameter(..., bind_to_instrument=False) and the intension was that if a parameter was assigned as an attribute, it should also be bound to the instrument (which basically amount to adding it to the parameters dict.

I would be tempted to suggest that:
We fix the bug such that add_parameter with bind_to_instrument=False works correctly but make that behaviour warn and recomed not doing that highlighting snapshot_exclude as an alternative. Would that work for you?

That should work, yes.