Array index out of bounds error on object model node

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.

Tinchus

@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

OwenD

@Tinchus
My guess is daemon.g is starting to run before the heaters are defined in config.g
Try something like this

if 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"

Tinchus

@OwenD Im sure you are right about the reason, but solution is not working because the status whuile the error is being reported is "idle". As I have posted on another topic, what I see is that seems like config.g is not being fully processed?
When error happens, in DWC the re is no tool configured, heaters, nothing... and status is "idle".
If I click on config.g, and save it and confirm the restart, everything goes normal again.
My guess real problem is the raspi image version Im using. 32 bit full version doesnt work, image is not bootong. 32 bit lite works, but not usefull for me because I have a touch screen connected.
So Im using the 64 bits full version.
I have a raspi 3 B+
What do you think?

OwenD

@Tinchus
The code I wrote will work when the status is idle, however I had a typo (now fixed).
I had #heat.heater instead of #heat.heaters
I don't run SBC, so I have no idea on that.