This release adds some usability improvements, and fixes an annoying bug in the firmware.
An oft-requested feature was for the Step view widget to display which step already has been applied.
Note that this is independent from whether you actually clicked the button: it will consider the step active if applying it would not change anything.
The firmware had a bug where if the Spark couldn’t find the network, it would retry before the previous search was finished. This would significantly slow down everything.
Changes
Firmware
Fixed a bug where the controller becomes very slow if Wifi is unavailable.
Changed filter implementation in Setpoint.
The filter levels themselves have changed
The filter levels are available simultaneously
Independent PID derivative filter
The derivative is now taken from an automatically selected filter level, so it is indepedent of the filter chosen.
The proportional part of the calculation uses the selected filter, but can now be set much shorter.
Changing PID Kp now does not affect integral output (it also scaled to keep the same output)
More accurate calculation of achieved PWM value. This resolves apparent peaks at the start of the cycle.
Update interval tracking and adjustment for PID and filter to the average interval is exactly 1 second
User interface
Improved display of pending state in Digital Actuators and Motor Valves.
State is pending if one or more constraints block it.
A spinner is displayed over the desired state.
If the actuator is not driven, you can toggle the state back to the (non-constrained) setting.
A tooltip displays which constraint is currently blocking the state change.
The Graph now displays a message if no data is available for the current settings.
The “Apply Step” button is colored green if the step is currently active (matches the current state).
If a value was changed during the Step view prompt, it is persisted in settings.
Changed multiple parts in Process View:
Split the Pump in two parts: Pump, and PWM Pump.
Pump can be either manual, or linked to a digital actuator.
PWM pump is linked to a PWM (big surprise), and will turn slower/faster depending on PWM setting.
Actuator Valve can now also be linked to a Digital Actuator.
Display settings are reset when removing all service blocks.
Note
We have created a new category on the forum for release notes and from now on will create a new topic for each release to make it easier to discuss the changes.
When a PID goes inactive it sets it’s output to zero only once to allow you to set the pwm manually later. Settings for the PWM block were stored when it was last configured, not when the PID changed the setting.
I suspect that on reboot the pwm was created after the inactive PID and included a setting.
I’ll try to reproduce it.
Can you confirm this theory by:
confirming that the PWM setting is constant since the reboot
setting it to zero and confirming that it stays at zero, also after a reboot
A possible fix is perhaps to split manual and PID applied setting of the pwm and only store a manually applied setting. I’ll have to think if this is also possible in other places.
All seems to be as it should now, I noticed the cooling after the update this morning, it was previously disabled as it is currently empty, I reapplied the “disable” but had to leave it until later in the day. I noticed it had been cooling to a previously set 11degs, albeit the set point was inactive. It stopped when I disabled the Cool PWM. I have just recycled the settings enable fridge constant and then disable and it seems to work. Have also rebooted and remains at zero.
Whilst in the disabled state I have applied a manual 18% duty to the heat PWM and it has started to heat despite the set point being disabled, I now can’t change it manually.
In addition it now won’t respond to the disable command and is still continuing to heat as if to follow the set point. Similar to the issue I first reported.
When you disable the setpoint or PID, you can set the pwm manually.
I have been able to reproduce the issue.
The problem is that the order the blocks are recreated at boot is different than the order in which the settings were applied.
If you disable a setpoint or PID after manually setting the pwm, the PID sets the pwm to zero.
If at restart the PID is loaded first, it has no pwm to disable. The pwm is created with its last manually applied settings, which is enabled.
Because the inactive PID does not continuously set the pwm to zero, it stays at the manual setting.
It’s a hard problem that I have to think about for a bit.
Since I have to specify in a file that I have 2 spark v2 with the addresses, why this late in the game do I still need to disconnect 1 to then update the second one? Why aren’t you reading said file and then running the firmware update on all specified addresses?
NOTE: Using RPi v3 with 2 Spark v2 connected via USB cable
To spare you the detailed technical explanation: streamlined firmware updates are in development right now.
Behavior will be to update firmware of the currently connected Spark(s) while everything is running. We haven’t turned it on yet in the UI because we have some issues with updates over USB (it already works nicely over Wifi).
I think this may be an issue with old deprecated objects. Could you please export your blocks? (spark service page, actions). If it is what I think that error message is saying, you may be able to resolve it manually before we release a fix tomorrow.
Thanks for the upload! It seems pretty clear where the problem comes from, but this will require some software changes. For now I’ll just roll back the hotfix.
