Motor current idle factor not working over canbus?
-
I have tested this in both 3.5.3 and 3.6.0-beta.1, and both appear to work correctly for me, with the axes on the mainboard-as-expansion-board controlling normal axes.
@mike_b are you controlling normal axes, or extruders, on the Mini 5+ expansion board? If it's extruders, I'll redo the tests with the extra motor configured as such.
Test setup: two Mini5+, running 3.6.0-beta.1. First board is on my normal bedslinger, second board has 1 motor attached to driver 0, and only has M954 A60 in its config.g. Configured motor as U axis, with same parameters as X axis.
Test: Initially M906 I30 and M84 S30 were set. I changed M84 S10, and idle timeout dropped to 10 seconds, on motors connected to both boards following a move of that axis (X and U tested). Changed M906 I100, motors on both boards maintain 100% current. Other M906 I# and M84 S# values tested, with the correct behaviour observed. So appears to be working correctly in 3.6.0-beta.1.
Reverted firmware to 3.5.3 on both boards, and ran tests again. Same result, so it seems to working as expected.Ian
-
Hey @droftarts - I'm controlling normal axes (the z-axis motor specifically) on the Mini 5+ expansion board. Since my z-axis is belt driven, any changes in the idle current are quite noticeable; for example, my print bed drops like a rock :D. Is there anything I can do on my end to help with this debugging? For example, make a video of the behavior? Post my full config? Let me know
-
Hey @dc42, I just realized I left you hanging! Back on Sept 12, I replied with "Let me get back to you this weekend," but I got caught up in moving to a new house and haven't had much time to follow up. Sorry about that!
-
@mike_b said in Motor current idle factor not working over canbus?:
Is there anything I can do on my end to help with this debugging? For example, make a video of the behavior? Post my full config? Let me know
Config.g would be good, then I can replicate your setup. Video if you've got time! Is it multiple motors combined to make Z axis? I didn't test that.
Ian
-
@droftarts ok, sounds good, I'll try to get this for you this weekend. And to answer you question: I am running 4 motors on the z-axis
-
@mike_b I set up a test with 4x Z motors on the Mini 5+ as expansion board, M906 I# and M84 S# seemed to work correctly in RRF 3.6.0-beta.1 and 3.5.3. I connected a stepper motor too, and ran into this bug in 3.5.3 (fixed in 3.6.0-beta.1): https://github.com/Duet3D/RepRapFirmware/issues/1058
I reverted back to 3.5.2, and finally did manage to replicate your bug. The motors on the Mini5+ expansion board did respect any M84 S# time, but always dropped back to 30% idle hold. Interestingly, sending M906 I# also caused the machine axes to be reset (ie unhomed), which didn't seem to happen in 3.5.3 or 3.6.0-beta.1.
When you get the chance, please check the firmware version you have installed. Are you running in SBC mode? If you still experience problems, please post your config.g and any other relevant files.
Ian
-
Hey @droftarts, sorry about for the late reply, the new house and the move and still taking up all my time. Anyway, yeah, I'm still experiencing the same problem. Here is a of my firmware, all 3.5.3. My setup is two Mini 5+ boards and SBC mode. Here is my
config.g
on the expansion board:M906 I90 M954 A40
The issue happens whenever I remove the M906 command from the expansion board config. Below is my
config.g
for the main board. I'm very much new to duet so please do let me know if I'm doing anything dumb:; get variables M98 P"/sys/constants.g" ; General G90 ; absolute coordinates M83 ; relative extruder moves ; Wait a moment for the CAN expansion boards to become available G4 S2 ; Kinematics; Cartesian M669 K0 ; Drivers M569 P0.0 S1 D3 V9 ; x0 M915 P0.0 S10 ; x0, stallguard threshold M569 P0.1 S0 D3 V9 ; x1 M915 P0.1 S10 ; x1, stallguard threshold M569 P0.2 S0 D3 V9 ; y0 M915 P0.2 S10 ; y0, stallguard threshold M569 P0.3 S1 D3 V9 ; y1 M915 P0.3 S10 ; y1, stallguard threshold M569 P40.0 S1 D3 V9 ; z0 M569 P40.1 S1 D3 V9 ; z1 M569 P40.2 S1 D3 V9 ; z2 M569 P40.3 S1 D3 V9 ; z3 M569 P121.0 S1 D3 V2 ; e ; ---- axes M584 X0.0:0.1 Y0.2:0.3 Z40.0:40.1:40.2:40.3 E121.0 ; axis mapping M350 X16 Y16 Z16 E16 I1 ; microstepping with interpolation M906 X1200 Y1200 Z1200 E500 ; axis driver currents M917 X100 Y100 Z100 E70 ; set motor standstill M92 X79.87 Y79.80 Z160.31 E722.76 ; steps per mm M208 X-10:270 Y-15:270 Z0:295 ; minimum and maximum axis limits ; ---- motor idle M84 S600 ; idle timeout, 10min M906 I95 ; idle current, 95% ; ---- accelerations and jerks M203 X15000 Y15000 Z6000 E2000 ; maximum speeds (mm/min) E max: 8.3mm/sec, 20mm^3/sec M201 X6000 Y6000 Z1000 E1000 ; accelerations (mm/s^2) individual axes M204 P6000 T3000 ; accelerations (mm/s^2) total motion, (P)rinting and (T)ravel M566 X1200 Y1200 Z200 E400 P1 ; maximum instantaneous speed changes (mm/min) ; ---- temp Sensors M308 S0 P"0.temp0" Y"thermistor" A"Heated Bed" T10000 B3892 ; bed M308 S1 P"121.temp0" Y"pt1000" A"Nozzle" ; nozzle M308 S2 P"40.temp0" Y"thermistor" A"Filament Dryer" T10000 B3892 ; filament dryer ; Fans ; --- air pump; brushed DC motors should operate nicely with a PWM freq of 50 to 100 M950 F0 C"0.out2" Q250 M106 P0 C"Tool fan" S0 B0.0 H-1 L0 X0.5 ; --- turn on auto when heatbreak is 45C M950 F1 C"121.out2" M106 P1 C"heatbreak fan" S0 B0.1 H1 T45 L0 X1 ; --- BAG enclosure fan 1 M950 F3 C"!0.out3" M106 P3 C"BAG fan 1 (weak)" S0 B0.1 H-1 L0 X1 M950 F4 C"!0.out4" M106 P4 C"BAG fan 2 (strong)" S0 B0.1 H-1 L0 X1 ; Heater, bed M950 H0 C"0.out5" T0 Q500 ; create heater #0 M140 P0 H0 ; configure heated bed #0 M143 H0 P0 T0 C0 S140 A0 ; heater monitor #0 for heater #0 M307 H0 R0.645 K0.227:0.000 D11.51 E1.35 S1.00 B0 ; PID tune ; Heater, extruder M950 H1 C"121.out0" T1 ; create heater #1 M143 H1 P1 T1 C0 S310 A0 ; configure heater monitor #0 for heater #1 M570 H1 P15 T20 ; fault only after 15sec and 20C excursion if global.hotend == "magnum" M307 H1 R2.510 K0.449:0.000 D5.91 E1.35 S1.00 B0 V23.7 elif global.hotend == "mosquito" M307 H1 R3.039 K0.404:0.000 D5.22 E1.35 S1.00 B0 V23.4 else M307 H1 B1 ; Endstops M574 X1 S4 M574 Y1 S4 M574 Z0 ; Tools M563 P0 S"T0" D0 H1 F0 ; create tool #0 M568 P0 R0 S0 ; initial tool #0 active and standby temperatures to 0C if global.nozzle_diameter < 0.6 ; heater feedforward for tool 0 M309 P0 S0.08 if global.nozzle_diameter >= 0.6 M309 P0 S0.3 ; z-probe dock M950 S0 C"out6" Q50 ; servo, assign GPIO port 1 to out9 (Servo header), servo mode M950 J0 C"!0.io0.in" ; sensor ; z brake M569.7 P40.3 C"out1" S100 ; accelerometer; I is the orientation M955 P121.0 I24 ; sensorless homing M915 X Y R0 F0 ; extra sensors M308 S10 Y"mcu-temp" P"0.dummy" A"0.MCU" M308 S11 Y"mcu-temp" P"40.dummy" A"40.MCU" M308 S12 Y"mcu-temp" P"121.dummy" A"121.MCU" ; electronics bag fan M950 F5 C"40.out6" M106 P5 C"electronics fan" B0.1 H11 T45 L0 X0.7
Finally, I know I did mention uploading a video, and I still can, if you think it would be helpful. However, it really wouldn't be too exciting, you'd just see the printer start up, and in the case when the expansion board config file lacks the line
M906 I90
the z stage would drop... I have the cracks in some plastic parts at the bottom of the printer to prove it Anyway, let me know if there is anything else I can do to help! -
@mike_b Okay, from your screenshot you're running in SBC mode:
I'll check with @chrishamm, as it is clearly working in 3.5.3 in standalone mode.
Ian
-
@droftarts yup, running in SBC mode. Is our current running hypothesis that this could be an SBC-related issue? If so, would you like me to test without SBC mode on my end?
-
@mike_b said in Motor current idle factor not working over canbus?:
Is our current running hypothesis that this could be an SBC-related issue? If so, would you like me to test without SBC mode on my end?
Please do, if you're happy to. I'm confident it's working in standalone, just need @chrishamm to check if/why it's happening in SBC mode.
Ian
-
Hey @droftarts, I hope this doesn’t make me sound crazy (though I wouldn’t blame you if it does!), but I just tested it in standalone mode, and the problem is still happening. I was sitting right next to the printer, with my hand under the print plate ready to catch it as soon as the low idle motor kicked in ... thankfully, I managed to catch it in time. I repeated the test several times with the same result. Anyway, I really don’t know what to do next. At this point I'm wondering if it's a hardware issue?
-
@mike_b Can you post your config.g, and the config.g on the Mini 5+-as-expansion? There should be not M906 in the config.g of the expansion board.
Ian
-
Hey @droftarts, I shared the configurations for both boards just a few days ago - you can find them here
I need to include the
M906 I90
command in theconfig.g
file for the expansion board; otherwise, the motors default to the default idle current, which causes my print plate to drop. For testing purposes, I remove that line. So, when I say the issue persists, I mean the problem still occurs when the M906 command is omitted from the expansion board’sconfig.g
file. This was a workaround recommended by @dc42 himself here. Sorry, I know this is all a bit confusing, happy to jump on a quick voice call, to explain everything, if you think it could help?EDIT: fixed links
-
@mike_b said in Motor current idle factor not working over canbus?:
Hey @droftarts, I shared the configurations for both boards just a few days ago - you can find them here
Sorry, senior moment, and that I was looking on my phone, I missed them!
I need to include the
M906 I90
command in theconfig.g
file for the expansion board...I understand that. I didn't have it in the expansion board config.g in my test setup, so I need to work out the differences between your setup and mine. Unfortunately I had to take my setup apart to do some 3.6.0-beta.2 testing, and I won't be able to put it back together to test until early next week.
I've had a look through your config.g, and the only thing that stands out to me is that your drives are running in stealthChop mode (M569 ... D3 Vn) while I ran mine in spreadcycle (M569 D2). You also have stallguard enabled on X and Y axes. Could you test without stallguard and with the drivers in spreadCycle? I'm not sure why this would make a difference though. Otherwise I'll try and test early next week with your config.g. I don't feel like this is a hardware issue, just yet.
Ian
-
This post is deleted! -
@droftarts said in Motor current idle factor not working over canbus?:
Sorry, senior moment,
LOL, no worries, I know the feeling!
Could you test without stallguard and with the drivers in spreadCycle?
Just tried it, unfortunately no luck, problem still persists.
Otherwise I'll try and test early next week
Thank you! And please do let me know if there is anything I can do on my end to help with the debugging.
-
Hey @droftarts - just noticed this issue has been closed in github. Was this by mistake? Or has there been some resolution I'm not aware of?
-
@mike_b I was able to replicate your issue in old firmware, but not with the updated versions, so as far as we can tell it's fixed. However, it doesn't explain why it's still an issue for you. Unfortunately, I haven't had time to rebuild the test set up to test with your config.g. I will try to early next week.
Ian
-
@droftarts Ok, thanks! I'll repeat here what I posted on github, because I think it's important: I really don't want to come across as overly demanding - I fully appreciate how challenging it is to allocate resources in an open-source project. That said, the safety implicating of this particular issue are significant. I do have brakes on my z-stage motors but brakes clearly don't help in this situation. Although I guess you could argue a belted z-stage is a terrible idea in the first place anyway, again, I deeply respect the effort it takes to maintain an open-source project, so please don't take this as an entitled complaint - just a genuine concern I felt was worth sharing.
All that siad, I’m more than happy to take a more active role in debugging this issue, whether it involves hardware (I have multimeters, oscilloscopes, etc.) or software troubleshooting.
-
@mike_b lets see if @droftarts can replicate it with your config.g and take it from there.