Issues with FW 3.0.6RC  

Re: Issues with FW 3.0.6RC

Vojtech

I totally agree with what you are saying here. S3D has a reason which is simply not valid; I always print perimeters and loops before infill, so any potential "blob" on a lift (following a retract and wipe) will be internal. Moving across a part before a lift is daft.

Is it not therefore time to remove S3D from your list of supported slicers?

This really is their problem to solve and not one for Prusa Research.

There are enough good slicers out there which do work properly and produce excellent prints.

Peter

Re: Issues with FW 3.0.6RC

I always print perimeters and loops before infill
So, you never print models without infill, right? 😉

Re: Issues with FW 3.0.6RC

> Is it not therefore time to remove S3D from your list of supported slicers?

S3D is a very good slicer. It is very quick, it has very good supports. We have to support them.

But you, the users, shall contact them to change their G-code generator.

Vojtech

Re: Issues with FW 3.0.6RC

Voitech

Could you please write in couple of sentences what exactly we haven't to request from S3D. I'm afraid I'm not qualified to explain all this story to them. But as S3D is my only slice, interested in the solution.

Janis

Re: Issues with FW 3.0.6RC

I always print perimeters and loops before infill
So, you never print models without infill, right? 😉

No, but when I do that, I print the perimeter before the loops.

Almost all my models have a level of infill (I don't print too many vases nowadays...), but I have recently been limiting the infill to 2.5%

Peter

Re: Issues with FW 3.0.6RC

Voitech

Could you please write in couple of sentences what exactly we haven't to request from S3D. I'm afraid I'm not qualified to explain all this story to them. But as S3D is my only slice, interested in the solution.

Janis

Janis

Simply that the Z lift for the next layer must be carried out prior to the move to the start position for the next layer.

Peter

Dear Sirs

I am currently experiencing difficulties with my printer which appear to be due to the way in which S3D works in that at the end of each layer the nozzle is moved to the start position of the next layer before being raised to the next layer height.

Unfortunately the move before raise is causing damage to the model and giving rise to the possibility that the model will be knocked off the build plate therefore I would ask that you amend the program to include the option that the nozzle is lifted to the next layer height prior to being moved to the start position of that layer.

Many thanks in advance

Regards
...

Re: Issues with FW 3.0.6RC

Voitech

Peter

Dear Sirs

I am currently experiencing ...
...

Many thanks, Peter!
Just posted that to the S3D technical support:)

Janis

Re: Issues with FW 3.0.6RC

> I see that there is a "Layer Change Script" Tab in there. Won't adding G4 right there produce the same results instead of changing my post processing script? I do like being able to send my gcode to octopi via post processing.

No, adding G4 into the layer change of Simplify3D settings produces a different code. If you put G4 into the layer change snippet, G4 will be placed before the XY move, not after the XY move and before the Z move.

Would you please post the S3D post processing script for sending to octopi? Maybe they could be combined?

.......

Vojtech

Here is the script I currently have for Post processing:

curl -k -H "X-Api-Key: XXXXXXXXXXXXXXXXXXXXXXXXX" -F "select=false" -F "print=false" -F "file=@[output_filepath]" "http://octopi:5000/api/files/local"

Most of this is from an existing post somewhere on this forum. But please note, I do run Linux as my desktop operating system (Ubuntu 16.04 LTS).

Also I have no problems testing out beta firmwares if you want me to 😉 I do know there are some people on here that would LOVE to know what GIT tags to use to get the firmware from github that will build correctly.

Re: Issues with FW 3.0.6RC

Ayork

Does this firmware (3.0.6 RC3): https://github.com/prusa3d/Prusa-Firmware/tree/MK2 not build correctly? It does for me and is the latest pre-release.

Peter

Re: Issues with FW 3.0.6RC

Many thanks, Peter!

Janis

Pleasure to assist!

Peter

Re: Issues with FW 3.0.6RC

Many thanks, Peter!

Janis

Pleasure to assist!

Peter

Moment ago receiver this response from S3D "Thank you for contacting Simplify3D support! I would be glad to help you with this. Lifting the head before moving to the next layer's start point can create several different print defects depending on the extruder and hotend type, which is why this behavior is not the default. You can, however, effectively create this behavior by enabling retraction vertical lift, as well as forcing retractions between layers (on the Extruder tab and the Advanced tab, respectively).

Please let me know if you have any more questions, I'd be happy to help."

Re: Issues with FW 3.0.6RC

Janis

Unfortunately, I am not a fan of S3D and I do not have it installed on my computers; maybe Vojtech will be along shortly to advise further.

However, I would suggest that this may be a somewhat "cobbled work-around" which will have implications elsewhere.

Peter

Re: Issues with FW 3.0.6RC

Ayork

Does this firmware (3.0.6 RC3): https://github.com/prusa3d/Prusa-Firmware/tree/MK2 not build correctly? It does for me and is the latest pre-release.

Peter

First off, the name is "Ayourk". and 2nd; I keep gettiing an error such as:
sketch/language_all.cpp:2:33: fatal error: configuration_prusa.h: No such file or directory
#include "configuration_prusa.h"
^
compilation terminated.
exit status 1
Error compiling for board RAMBo.

I know this is a case sensitivity issue that Windows overlooks, but Linux won't. So I have to go into language_all.cpp and change configuration_prusa.h to Configuration_prusa.h each time I do a git pull.

I did find that it is easier for me to use https://raw.githubusercontent.com/ultimachine/ArduinoAddons/master/package_ultimachine_index.json on Arduino 1.6.8 (as suggested via http://reprap.org/wiki/Rambo_firmware ) instead of http://prusa3d.com/downloads/others/rambo_arduino_addon.zip which is an older format.

Then I get the following error:
Bootloader file specified but missing: /home/ayourk/.arduino15/packages/rambo/hardware/avr/1.0.0/bootloaders/stk500boot_v2_mega2560.hex


Which means that there is a file missing. I've seen many posts by PJR here in the forums where he states that he doesn't have a clue how to fix this. I found the fix via http://reprap.org/wiki/Rambo_development that says where you can get that file. I then put it in place and when I do a Sketch --> Export Compiled Binary, I get 2 files in the "git/Prusa-Firmware/Firmware" folder: Firmware.ino.rambo.hex and Firmware.ino.with_bootloader.rambo.hex Without the bootloader hex file you won't get the 2nd file. Now as to whether I should be flashing my printer with a bootloader or not, I'll leave that answer up to Vojtech.

Re: Issues with FW 3.0.6RC

Ayourk

Apologies I mis-spelt your name.

The reason I don't have a clue how to fix the missing file problem is simple. On my system the file is not present and I do not get the error.

It is far easier to fix something when you can replicate the problem.

Peter

Re: Issues with FW 3.0.6RC

> Moment ago receiver this response from S3D "Thank you for contacting Simplify3D support! I would be glad to help you with this. Lifting the head before moving to the next layer's start point can create several different print defects depending on the extruder and hotend type, which is why this behavior is not the default. You can, however, effectively create this behavior by enabling retraction vertical lift, as well as forcing retractions between layers (on the Extruder tab and the Advanced tab, respectively).

That's their standard response.

It will avoid the issue of digging into the top layer with the time cost of the Z hop applied always. It certainly helps with the skipped Z steps on our MK2 to some extent. I think we still had a higher success rate when we added the G4 code before each G1 Z line with S3D due to the X jerk transferred to the Z axis. I will look into this issue for the 3.0.7 firmware, but for 3.0.6 you will be better off to apply the S3D post processing script to add the G4 code.

Vojtech

Re: Issues with FW 3.0.6RC

> Then I get the following error:
>Bootloader file specified but missing: /home/ayourk/.arduino15/packages/rambo/hardware/avr/1.0.0/bootloaders/stk500boot_v2_mega2560.hex

You can safely ignore this warning as the firmware is upladed over a serial line and the bootloader is already flashed onto the RAMBo board.

Vojtech

Re: Issues with FW 3.0.6RC

Going from 3.0.3 to 3.0.6 has broken my use of CURA gcode. I did the canned Batman symbol print and it seemed to start ok. I don't know what slicer was used to create it. I have RAMBo13a E3Dv6full. I have many successful prints from CURA on firmware 3.0.3 but when I loaded 3.0.6 the hot end moves very rapidly to start position and drives the hot end into the bedplate and over stokes. I haven't really done more checks with other slicers though as I don't want to damage anything else. I did XYZ calibration and that seems fine.

Anyone else having CURA slicer problems. I use CURA because a model I downloaded has the INI files for each part I need. Better than typing in all the parameters myself.

I like the fixes that 3.0.6 have and would like to use it with full functionality. Is CURA a tested slicer?

Thank you for your time. Please let me know if there is anything I can do or provide to help diagnose the problem. Everyone I've shown that has 3D printer is impressed with my Prusa I3 MK2, quality and resolution! What a winner!

Re: Issues with FW 3.0.6RC

Jasen

There are a few Cura users having issues similar to yours. The primary slicer recommended and supported by PR is Slic3r and is included in the driver download package.

Cura V2 is very new and has a number of faults; I tend to use Cura 15.04.6 on occasion. You do need to ensure that the correct start GCode is added to slicers other than Slic3r.

Peter