OctoPrint Rejects models that are near size limit

[droidmunkey]

I am trying to print a model that reports "Model size: 104.63mm × 108.68mm × 19.05mm"

The M3D print bed size is "Base Print Area: 109mm x 113mm"

This should fit, but when i try it says "Could not print the file. The dimensions of the model go outside the bounds of the printer."

Also the gcode viewer grid box appears to be a different size than the bounding box in the slicer model editor. The model fits according to the slicer model editor and also Cura on my computer, but the gcode viewer in octoprint shows it outsize of the grid box.

[donovan6000]

Can you upload the model?

The dimensions of the printable region enforced by M3D Fio are 108mm × 107mm × 112mm, so the Y108.68 is too big. I'm not really sure where M3D got 109mm x 113mm since that's not even the boundaries they use in their software.

The grid size in OctoPrint's G-code viewer is determined by the dimensions in the currently selected printer profile. M3D Fio generates the micro_3d printer profiles to include the boundaries it enforces, so the G-code viewer grid should be an accurate size.

You can also enable the option to ignore print dimensions limitations to bypass the boundary checks.

[droidmunkey]

I tried a small model and it rejected it too oddly... Rebooting and running a rejected model still got a rejection, but the gcode viewer grid was a different size now - so I resliced it again and now it's working.... I guess OctoPrint was stuck in a weird state.

I will try and reproduce the bug after this print is finished

[droidmunkey]

And thanks for the great software! I use linux and my M3D was sitting in a box for a year because i had no software for it. I found out about octoprint and your plugin and set it up right away!

Great work!

[kuntaykunt]

Hello ,

I have the same problem. I tried 3 times. I did turn the model 45 degrees for the last one and sick of waiting , just ignored the print area.

Did you setup skirt droidmunkey ? I did for one.

The model is Low-Poly-Storm Trooper Body from thingiverse. (1169514)

I printed the darth vader version which is the same size without any problem.

[donovan6000]

M3D Fio enforces a max Z of 112. It turns out that Cura adds in a final movement to the end of the model which is about increases Z by about 3.5mm that I wasn't aware of. I don't think Cura has an option to disable it. You can visually see that final movement in this image of the shoulders. That last movement puts the storm trooper's max Z at 113.658 which is out of bounds. The darth vader body is actually about 2mm shorter than the storm trooper, so his max Z after the final movement is 111.545 which keeps him in bounds.

You can get around this by changing the last line of G-code in the sliced storm trooper from G0 F1200 X52.000 Y66.541 Z113.658 to something with a lower Z like G0 F1200 X52.000 Y66.541 Z111.658.

[kuntaykunt]

Oh , i see but it looks ok when i am in the model editor. It looked totally fine. I tried to move at the end of the bed to see if it calculates the edges of the printer body which happened as not ok when you try the put model edge of the bed area.

I started the printing. I think i need to wake up around 6 hours later too see if anything goes wrong.

By the way i am having another issue right now , i do not know if i open a new topic or not. While the printer is printing , it stops the cooler fan around 1-2 secs then it continues. I am playing with retraction settings. The profile i am using is in the attachment.

m3d_pla.ini.zip

I checked again for the model size. It is as below ;

Model info

Model size: 43.52mm × 43.25mm × 108.20mm Estimated total print time: 03:19:39 Estimated layer height: 0.20mm Layer count: 543 printed, 1082 visited

Then it should be : 108.20 + 3.5 = 111.7 mm (I think this should be fine ?)

G-Code is attached. stormtrooper_lowpoly_body.gco.zip

[donovan6000]

I didn't know about the final movement that Cura adds in, so M3D Fio's model editor doesn't account for it. You shouldn't have any major problems since it's only the last movement that isn't extruding anything that goes out of bounds. Your Z motor will just grind for a second or two.

I don't really know how OctoPrint's G-code viewer determines the dimensions of the model, but you can look at the G-code to see exactly where the extruder moves. I know it determines the layer count by only counting layers that have positive extrusion, so maybe it only takes those layers into account when calculating the dimensions.

Can you upload the G-code of a file you sliced that has the fan issue. M3D has said that the printer can't source enough current to run the fan while the nozzle is heating up, so you might be experiencing that.

[kuntaykunt]

I saw that information , too. I see the issue every day but it is not important.

This one is very interesting. I have just saw the issue while printing the stormtrooper body around 10 mm from bed position.

G-code attached on my before comment.

See the last line :)

[donovan6000]

Make sure you have the 'Remove fan commands' option enabled. It should be enabled by default. If it is already enabled then your fan might have a loose connection or you might just have a bad fan.

[kuntaykunt]

They are all set enabled by default.They are ok.

[donovan6000]

There's probably an issue with your fan then. No G-code that affects the fan will get sent to the printer when using the 'Remove fan commands' settings aside from the commands that M3D Fio sends to start the fan at the beginning of the print and stop the fan when the print is finished.

[droidmunkey]

This is from thingiverse. If i scale the 'frame' down to 50% and rotate it, I can make it fit with no problems in the model editor.

But the sliced version won't print, it says it's out of bounds (and it shows it as such in the gcode viewer) - I think there is a problem between the model viewer and the slicer.

Wind_Bike.zip

[droidmunkey]

I checked the "center model" checkbox in the m3dflo settings and it started... How does that work? Will that reduce print quality?

[droidmunkey]

It says "Object to large to center on print bed" and didn't work.

[donovan6000]

What's the exact XYZ scale and rotation that you used in the frame that caused it to fit but fail the boundary checks?

The tooltips explain what all the settings do. The center model pre-processor stage positions moddle in the middle of the print bed, and it'll further reposition the model to make it fit in bounds if it's out of bounds after being centered. The 'Object to large to center on print bed' notification indicates that the model had to be repositioned to to fit in bounds.

[droidmunkey]

Alright I have more info.

I had another model fail to print because the "dimensions of the model go outside the bounds of the printer" - Everything looked fine in gcode viewer and the model editor/slicer. After restarting octoprint (through the menu) the gcode clearly went out of bounds.

The problem isn't with the model, something is getting out of sync in the cura slicer / model viewer layer it seems.

What does the "save" button do in the model editor- are you actually changing the STL file on the disk or generating a temp file for the slicer to work with?

[donovan6000]

Can you upload the upload the model and the list the changes you made to it's position, rotation, and scale so I can recreate it?

The save button saves a local copy of the current scene as an STL so that the user can slice the file in another slicer. It doesn't affect the original STL at all.

[droidmunkey]

I made no changes to the file, I simply loaded it up and sliced it. After restarting octoprint - Reslicing the same file without changes worked as expected.

On Tue, Apr 5, 2016 at 6:34 AM, donovan6000 notifications@github.com wrote:

Can you upload the upload the model and the list the changes you made to it's position, rotation, and scale so I can recreate it?

The save button saves a local copy of the current scene as an STL so that the user can slice the file in another slicer. It doesn't affect the original STL at all.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/donovan6000/M3D-Fio/issues/122#issuecomment-205749291

[donovan6000]

Not really sure why that happened. Did you make any changes at the modify profile screen? OctoPrint's CuraEngine plugin will use a default slicer profile if detects errors in the slicer profile being used, so incorrectly modifying the profile could cause what you experienced.

[droidmunkey]

I found something.

I wanted to copy the cura profile from the 'advanced settings' dialog, and i noticed the machine size was TOTALLY wrong.

Attached is the bad copy, which showed the rectangular gcode window.
The Good copy is after restarting octoprint - the dimensions had changed back to the correct values.

Something is causing the machine dimensions to get messed up after long prints. It happens pretty consistently. This might be on Octoprint and not you

CuraProfileGood.ini.txt CuraProfileBad.ini.txt

[droidmunkey]

OK it happened again. I tried to slice a file while printing was in progress. Slicing while printing is in progress might be the culprit.

Oddly, the machine size is different then CuraProfileBad above - so it's not defaulting or taking a different machine's info (I only have one machine configured anyway) - it must be coming from somewhere else

[machine] machine_depth = 117.0 has_heated_bed = False extruder_offset_y1 = 0.0 extruder_amount = 1 machine_center_is_zero = False extruder_offset_x1 = 0.0 machine_shape = Square; Square, Circular machine_width = 104.0 machine_height = 112.0

[donovan6000]

It seems like it's not restoring the printer profile after slicing the model. OctoPrint will only ever slice a file in the center of the bed, so M3D Fio changes the size of the bed before slicing to trick OctoPrint into positioning the model differently. Your seeing those different bed sizes when you go to slice again since the original printer profile isn't being restored for some reason.

I imagine that this is happening since M3D Fio is experiencing an error when restoring the original slicer profile and model. It does that immediately before restoring the printer profile, so an error there would prevent the original printer profile from being restored. Can you upload the OctoPrint log of when this issue happened? You can get them by going to the 'Logs' tab in OctoPrint's settings.

This could be related to the differences in file paths for different operating systems. What operating system are you using so I can try to recreate this?

[donovan6000]

It's been awhile since this issues had a response, so I'll probably close it in a couple of days. Let me know if you still have any interest in resolving this issue.