Need to see a backtrace. Perhaps you are just on the borderline of stack usage, or something going crazy? Looking at DukOvmsMetricFloat(), it just return the metric AsFloat(), and for float type metrics that should just be zero if not defined. Regards, Mark.
On 29 Mar 2018, at 8:58 AM, Greg D. <gregd2350@gmail.com> wrote:
Hi folks,
Does anyone know how DukTape scripting handles math with a metric that hasn't been updated yet?
I have a short example script in the OBDII ECU documentation which (should) calculate a power-per-speed metric for display on a HUD. Seems like it would be a useful example, and wanted to verify that it actually works.
OVMS> vfs cat /store/obd2ecu/10 ret1=OvmsMetricFloat("v.p.speed"); ret2=OvmsMetricFloat("v.b.power"); out = 0.0; if(ret1 > 0) { out=ret2/ret1; } out;
I have the module in the my Roadster, and the v.p.speed metric comes up as 0 kph (that's good - it's parked), but the power metric isn't provided by the car, so is blank when listing the metrics. I expected the code to return zero.
Instead, executing the script by asking for 'obdii ecu list' causes an immediate crash with a stack overflow in task AsyncConsole. If I initialize the power metric by hand (metric set v.b.power 0), the script runs just fine, returning 0 for the metric.
Oddly, when I first set it up on the desk (sans vehicle), so both of the metrics were blank, executing the script didn't cause crash.
Is there a way to make the code "Roadster safe", without dummying up the metric in, say, a startup script? Better, is there a fix for DukTape to handle this, or should I just increase the stack size in AsyncConsole?
Thanks,
Greg
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev