vintagepc / rpm-post Goto Github PK

the "maxrate" variable is being calculated to be zero incorrectly which then causes the gcode to extrude too slowly during the purge. I think this is partially due to line 114 of the code just setting the diameter to zero rather than pulling it from the gcode. The other part seems to be that the max_vol_rate is not being calculated correctly either. It's coming out as zero. From what I can tell, it is pulling that correctly from the gcode because filament_volumetric_settings has all the right values, but when it performs "max_vol_rate": min(float(filament_volumetric_settings[tool]),PRINTER_MAX_VOLUMETRIC) it comes up with zero.

In #5 it was reported the RPM script seems to leave stringier tips than the wipe tower.
Look into this and see why.

Looks like at the end of a purge, you invoke the extruder to retract by the value of "retract_length_toolchange". However, when the extruder goes to start printing again, it only re-primes the nozzle to the value of "retract_length". This causes the printer to print air for a little bit till the filament reaches the nozzle.

; retract_length = 0.8,0.8,0.8,0.8,0.8
; retract_length_toolchange = 3,3,3,3,3

I'm not sure why the original gcode is not using the "retract_length_toolchange" but it seems like the easiest fix would be to use the "retract_length" value instead.

I had to disable/remove the wipe options to get this working initially. Figure out how to re-implement those; it'll be tricky since you no longer have the purge volumes available to calculate from the tower, and they can be tricky to determine based on the object, owing to Plicer isssue 2855 (prusa3d/PrusaSlicer#2855)

My MK2.5 stalls out sometimes when triggering the purge bucket due to resistance in the purge unit. Some of the other folks using this setup temporarily increase the current via a m907 command temporarily (say from 300 to 450 or higher). It would be cool if you could add this to the script. Maybe similar to your bucket position command we could add a line for nominal and high current values in a similar fashion (in the start of gcode section).

I've already taken a few springs off the purge mechanism but I think the MK2.5 not having the same stepper controllers as the MK3 leaves it a bit underpowered.

Filament ejected during the ramming sequence cools while the toolchange is happening. This appears to interfere with blob formation.

It seems like the BB3D RPM wants specific "blob" sizes when it purges and folks just run the purge several time if they haven't extruded enough material. As it stands right now (according to your readme file) it can over-purge into the bucket and get messed up correct?

Once your script calculates the purge volume it is going to purge, could it not round that up to a multiple of the standard blob size and run the purge / eject routine the correct amount of times to satisfy that? I should just start reading your code, but are you pulling the purge values from: ;wiping_volumes_extruders &
; wiping_volumes_matrix
at the end of the gcode?

Bring over the features from the other scripts, namely the toolchange randomizer, and the support for the (or a) bucket mechanism