Array index out of bounds error on object model node

[curieos]

I'm writing a macro to handle driver errors, and it seems that accessing an array index greater than 2 throws an error, even when that array has 4+ objects. I can repeat this issue on two machines via echo move.axes[2].drivers[3], when the Z axis has 4 drivers assigned. I've verified with the object model that index 3 does exist on both. This is on firmware 3.4.6

[curieos]

@curieos I did some additional quick testing. I checked another machine on duet 2 with four z motors (the machines I initially tested are on duet 3), and the same command throws the same error. I then tested other arrays that contain more than 3 objects and those don't throw errors. I tried on another object that is an array index with an array (specifically tools[2].offsets[3] and state.restorePoints[2].coords[3]) and that didn't throw an error either, so it seems that it has to do with specifically move.axes[].drivers[].

[dc42]

@curieos thanks for your report. I have just returned from formnext and I will try to reproduce this next week.

[dc42]

@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+.

[curieos]

@dc42 Thanks for looking into it. Any chance the fix will get backported before the 3.5 release?

[dc42]

@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.

[oozeBot]

@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": ...

[oozeBot]

@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]

@oozeBot @curieos which Duets are you using?

[oozeBot]

@dc42 6HCs connected to Raspberry Pis in SBC mode.. Thanks!

[dc42]

@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.

[curieos]

@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.

[oozeBot]

@dc42 that fixed it! Thanks!! We've installed on our test machine and will monitor it closely for any issues.

[dc42]

@curieos I've put a 6XD build at https://www.dropbox.com/scl/fo/tb6tn4txjwopuvdwry3oz/h?rlkey=ipef1q3exolt3v9olczt3d545&dl=0 too.

[curieos]

@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.

[oozeBot]

@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]

@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

[dc42]

@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.

[Tinchus]

@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 S2

Im running duet3, SBC, and version 3.5.2 firmware

[dc42]

@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.