Array index out of bounds error on object model node
-
@curieos thanks for your report. I have just returned from formnext and I will try to reproduce this next week.
-
@curieos I confirm that this appears to be a bug in firmware 3.4.6. It works correctly in firmware 3.5.0-rc.1+.
-
@dc42 Thanks for looking into it. Any chance the fix will get backported before the 3.5 release?
-
@curieos I've already backported it into the 3.4-dev firmware source, so if we do a 3.4.7 release it will be included in that.
-
@dc42 good timing on this thread. This is also affecting us as the object model returned through DSF-Python does not return all heaters. We have 3 heaters (0=build plate, 1=hot end, 2=chamber). Only the build plate (index 0) is being returned in the object model - see below.
Please consider a 3.4.7 release to correct this while 3.5 continues development. Thanks
"heat": {"bedHeaters": [0, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1], "chamberHeaters": [2, -1, -1, -1], "coldExtrudeTemperature": 160, "coldRetractTemperature": 90, "heaters": [{"active": 0, "avgPwm": 0, "current": 24.3, "max": 155, "min": -273.1, "model": {"coolingExp": 1, "coolingRate": 0.101, "deadTime": 26.7, "enabled": true, "fanCoolingRate": 0, "heatingRate": 0.208, "inverted": false, "maxPwm": 1, "pid": {"d": 2.356, "i": 0.0017, "overridden": false, "p": 0.12604, "used": true}, "standardVoltage": 0}, "monitors": [{"action": 0, "condition": "tooHigh", "limit": 155}, {"action": null, "condition": "disabled", "limit": null}, {"action": null, "condition": "disabled", "limit": null}], "sensor": 0, "standby": 0, "state": "off"}, null, {"active": 0, "avgPwm": 0, "current": 2000, "max": 80, "min": -273.1, "model": {"coolingExp": 1, "coolingRate": 0.014, "deadTime": 50, "enabled": true, "fanCoolingRate": 0, "heatingRate": 0.01, "inverted": false, "maxPwm": 1, "pid": {"d": 49, "i": 0.0071, "overridden": false, "p": 1.4, "used": false}, "standardVoltage": 0}, "monitors": [{"action": 0, "condition": "tooHigh", "limit": 80}, {"action": null, "condition": "disabled", "limit": null}, {"action": null, "condition": "disabled", "limit": null}], "sensor": 2, "standby": 0, "state": "off"}]}, "httpEndpoints": ...
-
@dc42 If there is a possibility to pass us an unofficial build which corrects this, it will be more than appreciated! We made a commitment to a customer based on the (bad) assumption the full object model was available to query.. thanks
-
-
@dc42 6HCs connected to Raspberry Pis in SBC mode.. Thanks!
-
@oozeBot you can try the firmware build at https://www.dropbox.com/scl/fo/tb6tn4txjwopuvdwry3oz/h?rlkey=ipef1q3exolt3v9olczt3d545&dl=0 but be warned, although I tested the fix I didn't test anything else. Partial release notes are at https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x#reprapfirmware-347-in-preparation.
-
@dc42 Two 6XDs + Two 1LCs, also SBC mode. This bug isn't game breaking for us, it came up while I was writing macros to handle driver errors. It only affects one of four Z motors, and so far I've noticed if one errors they all follow. Not ideal, but it's uncommon enough that I think we can wait for a full stable release, assuming that's not too far away.
-
@dc42 that fixed it! Thanks!! We've installed on our test machine and will monitor it closely for any issues.
-
@curieos I've put a 6XD build at https://www.dropbox.com/scl/fo/tb6tn4txjwopuvdwry3oz/h?rlkey=ipef1q3exolt3v9olczt3d545&dl=0 too.
-
@dc42 That build fixes the issue I was having too. I think we can leave it on the test machine for now, I'll let you know if anything comes up.
-
@dc42 - has there been any further consideration of releasing 3.4.7 of RRF? Or could you provide me the 3.4.7 deb file for our package server? The issue is that during the apt-update process, it tries to downgrade from 3.4.6+ to 3.4.6.. Thanks
-
@dc42 - bumping this.
** edit ** I was able to rebuild the deb file and resign it with the updated 3.4.6+ firmware. Still would like to know if there will be a 3.4.7 prior to 3.5's release though.
Thanks
@oozeBot said in Array index out of bounds error on object model node:
@dc42 - has there been any further consideration of releasing 3.4.7 of RRF? Or could you provide me the 3.4.7 deb file for our package server? The issue is that during the apt-update process, it tries to downgrade from 3.4.6+ to 3.4.6.. Thanks
-
@oozeBot as we how to release 3.5.0 RSN it's likely that we will release 3.4.7 just before or just after 3.5.0, when we're happy that there are no bugs in 3.5 that we fixed that also affect 3.4 and that we want to back-port.
-
@dc42 seems the bug is back?
Im having this error:
8/23/2024, 10:31:22 AM Error: in file daemon.g line 4: line 0: array index out of bounds
This the daemon.g fiile:
while true
if state.status != "processing"
if (heat.heaters[0].current > 60) | (heat.heaters[1].current > 65) | (heat.heaters[2].current > 65) | (heat.heaters[0].avgPwm > 0.01)
M42 P3 S1
M42 P3 S1
else
M42 P3 S0
G4 S2Im running duet3, SBC, and version 3.5.2 firmware
-
@Tinchus that's not the same issue, it's not an array of arrays that is being indexed. Please check using the object model browser that you really do have heaters 0, 1 and 2 configured.
-
@dc42 Yes I have them. This is not a new installation. I re flasehd the image with a new sd card (the other was too old and giving problems)
This daemon file was the old one, no change at all.
heater 0 is my chamber, heter 1 is T0 heater 2 is T1 -
@Tinchus
My guess is daemon.g is starting to run before the heaters are defined in config.g
Try something like thisif state.status != "processing" if #heat.heaters = 3 ; edit to suit number of heaters you have in total if (heat.heaters[0].current > 60) | (heat.heaters[1].current > 65) | (heat.heaters[2].current > 65) | (heat.heaters[0].avgPwm > 0.01) M42 P3 S1 M42 P3 S1 else M42 P3 S0 G4 S2 else echo "Only " ^ #heat.heaters ^ " heaters initialized yet"