whpthomas / GPX

Gcode to x3g conversion post processor
GNU General Public License v2.0
98 stars 16 forks source link

Incorrect progress reported (Sailfish) #7

Open vitalif opened 10 years ago

vitalif commented 10 years ago

Hi! I have a Replicator 1 dual extruder clone - Wanhao Duplicator 4, upgraded to Sailfish firmware. I think it's strange, but files converted with GPX report wrong progress - it starts somewhere around 15-50% instead of 0%... And it was the same with stock makerbot firmware... What may be the cause?

dcnewman commented 10 years ago

On 27/05/2014, 1:55 AM, Vitaliy Filippov wrote:

Hi! I have a Replicator 1 dual extruder clone - Wanhao Duplicator 4, upgraded to Sailfish firmware. I think it's strange, but files converted with GPX report wrong progress - it starts somewhere around 15-50% instead of 0%... And it was the same with stock makerbot firmware... What may be the cause?

You need to

  1. Have this at the end of your start.gcode,

M73 P1 ;@body (notify GPX body has started)

  1. And the -p switch needs to be passed to GPX. (S3D does that automatically.) And double check -- I think it's -p, but I could have the name wrong.

Dan

vitalif commented 10 years ago

I've always used -p... Just tested with M73 P1 ;@body in the end of start.gcode and it didn't help - the progress started at 13%. (I didn't remove M73 P0 in the beginning of start.gcode - may it be the cause?)

dcnewman commented 10 years ago

On 27/05/2014, 11:04 AM, Vitaliy Filippov wrote:

I've always used -p... Just tested with M73 P1 ;@body in the end of start.gcode and it didn't help - the progress started at 13%.

Well, that's part of what you need I believe as I know I saw the same symptoms when my start.gcode was missing

M73 P1 ;@body (notify GPX body has started)

When I added that, I then got correct percentages. However, I also had other things in my start gcode (e.g., M73 P0 at the beginning). And so it may be a combination of things you need.

Dan

whpthomas commented 10 years ago

Hi,

Sorry for taking so long to respond. I have spent a lot of time working in china this year, and only took my iPad with me.

GPX progress includes both pre-heat and print time in its estimate. So if you have both a heated build plate and extruders it will sum together these delays and subtract them from the total build time. So if you do a quick print, the pre-heat will be more, on longer builds it will be less. I found that this made sailfish print time estimates more accurate overall. But I a quite willing to change this behaviour based on user feedback.

vitalif commented 10 years ago

Oh, that's interesting. I usually do preheat prior to printing, so it logically takes "zero" time... My personal opinion is that it would be better to not take it into account... But maybe it should be a parameter? Also, the heating time may vary depending on printer and firmware - for example Sailfish heats both extruders and HBP together (because 350W power supply allows it on my printer), but the stock firmware heated them in sequence... So how does GPX calculate heating time?

dcnewman commented 10 years ago

FWIW, and Henry likely already knows this

//The build time is not calculated from the start of the build, it's calculated from the first non zero build
//percentage update sent in the .s3g or from the host
float timeLeft = (elapsedSecondsSinceBuildStart / (float)(buildPercentage - startingBuildTimePercentage)) * (100.0 - (float)buildPercentage); 

Dan

//Set the starting time / percent on the first HOST_CMD_SET_BUILD_PERCENT //with a non zero value sent near the start of the build //We use this to calculate the build time

if (( buildPercentage > 0 ) && ( startingBuildTimeSeconds == 0.0) && ( startingBuildTimePercentage == 0 )) { startingBuildTimeSeconds = host::getPrintSeconds(); startingBuildTimePercentage = buildPercentage; } if ( buildPercentage > 0 ) elapsedSecondsSinceBuildStart = host::getPrintSeconds();

and then

//Returns the estimated time left for the build in seconds //If we can't complete the calculation due to a lack of information, then we return 0

int32_t estimatedTimeLeftInSeconds(void) { //Safety guard against insufficient information, we return 0 if this is the case if (( buildPercentage == 101 ) || ( buildPercentage == 0 ) || ( buildPercentage == startingBuildTimePercentage ) || ( startingBuildTimeSeconds == 0.0 ) || (startingBuildTimePercentage == 0 ) || (elapsedSecondsSinceBuildStart == 0.0)) return 0;

//The build time is not calculated from the start of the build, it's calculated from the first non zero build
//percentage update sent in the .s3g or from the host
float timeLeft = (elapsedSecondsSinceBuildStart / (float)(buildPercentage - startingBuildTimePercentage)) * (100.0 - (float)buildPercentage); 

//Safe guard against negative results
if ( timeLeft < 0.0 )   timeLeft = 0.0;

return (int32_t)timeLeft;

}

vitalif commented 10 years ago

I.e. you mean that preheat time shouldn't affect build time estimate in Sailfish?

dcnewman commented 10 years ago

No. Rather I was pointing Henry to how Sailfish estimates remaining build time. Unless you are running a Rep 2 or a Core-XY bot, you never see Sailfish's estimated build time remaining values.

vitalif commented 10 years ago

OK, so @whpthomas maybe you'll remove heating and homing time from build progress? Something like vitalif/GPX@837de3498d4dd5faf880e5cf51aaefb8489f536b (it works for me - the printing begins with 0%)