"Object doesn't fit print volume" after FW upgrade

hi all,

I'm ne to 3dPrint, I setup octoprint on an eeePc and all is working fine

Now i need to update the FW of my ER-20 from Marlin 2.0.5.3 to a 2.0.8 released as a branch from Eryone on Github

the problem is that I get this error " Object doesn't fit print volume"


Object in EE_Cubo40.gcode exceeds the print volume of the currently selected printer profile, be careful when printing this.

More

Object exceeds print volume in depth.
Object's bounding box: (20.00, -2.00, 0.00) Γ— (157.31, 124.31, 39.98)
Print volume: (0.00, 0.00, 0.00) Γ— (250.00, 220.00, 200.00)

You can disable this check via Settings > Features > "Enable model size detection [...]"

with the new FW but with the old one all is working fine with the same gcode

i try to read the M503 from the 2 FW but i not found any difference on bed dimension or anythings that seems to be related to this error.

can anyone help me?

here the 2 M503

https://drive.google.com/file/d/1SWgE2Jt7wL1C04t8sO-Tpbqvt4wk8ESE/view?usp=sharing

https://drive.google.com/file/d/1WlE5gX8y2UVtfJVZYnZqUbh9njUz-UY-/view?usp=sharing

The firmware makes no difference here, since what you've found is purely OctoPrint side. The gcode you uploaded had a movement outside the print volume (to -2), so it is warning you. If this is intentional, maybe for a prime line or similar then you can setup a custom bounding box in the OctoPrint settings, under printer profiles.

The question is that the gcode is exactly the same and yes , it has a line printed at the printing area limit.

I can immagine that octoprint read some info from the printer that effects this warning.

I'm the author of OctoPrint. No, it doesn't (unless you have some to me unknown third party plugin installed that actively queries information like that from the firmware somehow and then modifies OctoPrint's printer profiles). The only thing that this warning depends on is the information in the printer profile.

Really nice to meet you!

Thanks for your attention and your work!

I really can not understood what is going wrong because the profile is the same, the gcode too, the only thing that I change is the fw...

If you would like to investigate , I will try to help giving you all the logs and things you need

Also the access to my ssh if needed :wink:

I've given you the solution, if you want me to confirm that the solution is the solution, then the gcode file is the thing that we need.

My dear friend, your solution is not the solution, I'm sorry.

The problem maybe the gcode if with one fw or the other I have always the same warning but as I stated before, with the same gcode, same printer profile, I have no error with the 2.0.5.3 firmware.

I wish I cleared this point

Thanks for your help

Screenshot the printer profile (section with build volume and bounding box) and upload the gcode file. It's nothing to do with the firmware, really

I agree with @Charlie_Powell, to my knowledge as the one who's maintaining the code this cannot technically be the firmware. Still, if you want anyone to take a look at this, you'll need to share the GCODE file in question and a system info bundle with enabled serial.log and ongoing connection during file load from both firmwares, and also the printer profile you use for connecting. Note that if you are using a different printer profile in both cases, that would explain the change in behaviour as well. If you resliced the file, that could also be a reason. Also run in safe mode to be absolutely sure you don't have some third party plugin messing with things.

This all doesn't change though that this particular message -- if you are talking about this one:

image

is strictly dependent on your printer profile settings. I can't tell you anything else, what you are describing is simply impossible to be caused by a firmware change. The only way you can get this is by loading a GCODE file that has printed areas that exceed the configuration printer profile's bed volume incl. bounding box. There's no query being done against the firmware. There's not even a query being done against OctoPrint's server, the whole evaluation happens strictly on the client that doesn't even know nor care about the firmware.

this is the Gcode used for test:
https://drive.google.com/file/d/1UfpT_s6ESGp7xbX6tyeHOponfwAqrDGy/view?usp=sharing

and this is the configuration of the printer:

maybe the new firmware work batter and use the "PROMT_SUPPORT" or something similar so the printer send a message to OCTOPRINT ?

https://docs.octoprint.org/en/master/bundledplugins/action_command_prompt.html

No. Prompts look completely differently and can't produce a notification like I shared a screenshot of (is this the one you saw or not?). Your printer profile lacks a custom bounding box, as expected. So if your GCODE contains moves outside of the (0,0,0)x(250,220,200) print volume, this warning is working like it should. I can't tell you why you were not seeing it with the old firmware, but that you see it completely fits the so far available data.

There is this line at the start:


That is outside the print volume.

Also, as an unrelated issue, your start gcode in Cura is not working right, as these should have their values replaced:

M140 S[first_layer_bed_temperature] ; set bed temp
M190 S[first_layer_bed_temperature] ; wait for bed temp
G28 ; home all without mesh bed level
G29 ; mesh bed leveling/ABL
M104 S[first_layer_temperature] ; set extruder temp
G92 E0.0
G1 Y-2.0 X150 F2400G1 Z3 F720
M109 S[first_layer_temperature] ; wait for extruder temp

You should probably use curly brackets here, {} instead of the square ones. I'm not sure if the variable names are correct either, you can find a list here:
http://files.fieldofview.com/cura/Replacement_Patterns.html

For what it's worth: these are Slic3r/PrusaSlicer/SuperSlic3r variables. They definitely won't work in Cura, like Charlie mentioned, though.

Maybe I not explain my self well.l, I know there is the line outside the printing area.

For me is clear also that I can solve the warning setting up the bounding area

My question regards the warning that is not shown whit the 2.0.5.3 but is shown with the 2.0.8

For me the situation is clear but not solved

little update....

the FW is not the key....

today, with the same FW (2.0.8) he warning appear randomly with the same file opened in different moment,

ALWAYS there is the Y-2 movment but some times the message was shown , other times nothng appered...

so the FW is out of the equation

That's what I told you several times already. It cannot be the firmware. It's technically completely impossible.

Now... Do you use third party apps to start a print sometimes? A slicer like Cura or PrusaSlicer? Some mobile app? An LCD based client like OctoDash or similar? As I said, the warning gets evaluated and generated completely on the client side. So if you start a print from anything but the included UI, it won't get triggered even with a misconfigured printer profile.

I understand when you say that octoprint non take informational from the fw, but at that time it was the only difference I can see so I'm only reporting the situation.

Now, the printer is directly connected to a eeePc with octoprint installed, no slicer installed on the same eeePc, it is a clean install of Linux Mint,
No slicer used in the same session with the printer

The gcode viewer show the y-2 step but sometimes the warning is triggered, sometimes no.

I will try to report if I noticed when it is not triggered if it can help

It can be to a client that is slow?

Thanking a look to the console of chrome I noticed a warning

"terminal: detected very slow client ... Completely disabling terminal output during printing"

Do you reupload the file in question in between tests? The warning can't be triggered if the file hasn't yet been analysed and thus its dimensions aren't known yet. Analysis takes some time after initial upload, then triggers a file list refresh on the client side, then that has to go through before the information is available. If you upload, then select right away, analysis hasn't run yet and the warning only generates on file selection, so it won't generate then either.