Filament drive counting backwards

Aurimas

filament usage is correct, but the drive is going backwards
3.6.0-b2

magnets99

is the extruder motor set as backwards in the config.g?

do you know if that error is present on a stable release?

T3P3Tony

@Aurimas thanks for the report.

I don't think this is simply due to the extruder motor direction as set with M569 Sn because having that configured for either direction is down to how the motor is wired.

It would be very odd if the slicer was configured to emit negative extruder moves for extrusion and positive for retraction, however if that was the case then that might cause the odd display in DWC? I presume the sliced file is "normal" and extrusion G1 commands have positive E values?

Aurimas

@T3P3Tony you guys missed the fact where I say that the filament usage is reported correctly.
also the extruder drive was correct at the start.
I believe this is an error with the coding and the counter flips once it has reached certain distance
I believe it is a code bug with variable type definition - it simply cannot handle such a large number properly

@magnets99 it would be impossible to experiment due to the fact that it used over 12kg before it got to this point

magnets99

@Aurimas
oooo i see what you're saying
like some variable is declared as an int and only has 32,000 max value when it should be a Long or similar?
(i'm not a coder, I had a similar issue with an arduino that was counting a delay).

Looking at that screen shot, i had assumed that the filament usage was all time, not per print!
what size printer is that!?

Aurimas

@magnets99 that is our Vega970
https://aurarum.com.au/shop/aurarum-vega-970-idex-3d-printer/

T3P3Tony

@Aurimas Ahh right I see, that's possible. So it was counting up correctly to start with and then flipped at a certain point?

magnets99

@Aurimas
Wow that is a monster!
you could probably lost pla cast a whole engine block with that!

Aurimas

@magnets99 said in Filament drive counting backwards:

you could probably lost pla cast a whole engine block with that!

Reply

lol. it would depend on the size of the engine block

Aurimas

@T3P3Tony yes - it was correct to start with.
I am not sure at what point it flipped

T3P3Tony

@Aurimas assuming the print is still going, can you see what the move.virtualEPos and move.extruders[0].position are showing as in the Object model please

dc42

@Aurimas is that extruder driven by the main board or by a tool board? What is the extruder steps/mm?

Aurimas

@T3P3Tony no - print is finished

Aurimas

@dc42 no sure why would steps matter?
Filament counter reports correctly, while Extruders Drives got inverted mid print
These are two different counters from what I understand and because of that it has software setting issue

T3P3Tony

@Aurimas it's possible that the step counter is overflowing hence why dc42 wants to know the steps/mm of the extruder.

Aurimas

@T3P3Tony said in Filament drive counting backwards:

t the step counter is overflowing hence

its only 400/mm

T3P3Tony

@Aurimas thanks

Aurimas

@T3P3Tony @dc42 it doesn't really affect anything - I am just reporting that there is something in the code that is doing that.
thanks

dc42

@Aurimas the microstep counter from which the position is computed will wrap around at 2^31 microsteps. At 400 microsteps/mm that will occur after extruding 5368709 mm of filament. So this explains it.

Aurimas

@dc42 just as suspected
filament counter is counting correctly anyway.