Netfabb gcode at start

[greengecko 8]

Hi there,

I am a bit desperate. I started to print with my new ultimaker about two weeks ago and everything was fine. Then I wanted to have less stringing and updated the Firmware last week via Cura (which works fine) to see if that helps. . I actually use Netfabb (the 150 € Ultimaker version) most of the time (as it is simple and comfortable to use).

I managed to print decent print at about 190-200 degrees with PLA. Since the firmware upgrade Netfabb prints (printed via Printrun) do not start regularly anymore and at the wrong position (not in the centre, but rather at the edge of the build platform).

So when the print starts it goes to the x,y zero corner, crosses it diagonal and then does about 4-5 lines at this edge towards the y100 point. Previously after this it did extrude backwards and run really fast towards x0, y200 and then started exactly at the position that I moved the object in Netfabb.

Now this is no longer the case. After the 4-54 lines at the edge towards y100, it stays for about 5 seconds just over the platform oozes there and then starts immediately around there (which leads to an object within the edge of the build plattform. I looked at the starting Gcode in Netfabb, here it is and also reseted it to its previous values (loosing all my settings, though there were not many).

Can anyone tell me how to change this behaviour to the previous state.

THis is the Gcode that netfabb produces before the print:

M104 S193.00

M92 E14

G21

G91

G1 X0.00 Y0.00 Z5.00 F500

G90

M109 S193.00

G28

G92 X0.00 Y0.00 Z0.00 E0.00

G1 E0.00

G1 X0.00 Y0.00 Z5.00 F600.00

M106 S255

G1 X205.00 Y200.00 Z5.00 F5000.00

G1 X205.00 Y200.00 Z0.35 F5000.00

G1 X205.00 Y100.00 Z0.35 F2500.00 E200.00

G1 X204.00 Y100.00 Z0.35 F2500.00 E202.00

G1 X204.00 Y200.00 Z0.35 F2500 E402.00

G1 X203.00 Y200.00 Z0.35 F2500 E404.00

G1 X203.00 Y100.00 Z0.35 F2500 E604.00

G1 X202.00 Y100.00 Z0.35 F2500 E606.00

G1 X202.00 Y200.00 Z0.35 F2500 E806.00

G1 X201.00 Y200.00 Z0.35 F2500 E808.00

G1 X201.00 Y100.00 Z0.35 F2500 E1008

G1 X202.00 Y100.00 Z0.35 F50000 E708.00

G1 X0.00 Y200.00 Z0.00 F15000

G92 E-300.00

 

until here is the part that can be edited the rest seems to be thrown in without use control, so I assume the "error" occurs in the next bits...

G1 X0.0000 Y200.0000 Z0.0000 F3240.0000

M107

G1 X0.0000 Y200.0000 Z0.1800 F1200.0000

G1 X0.0000 Y200.0000 Z0.2000 F1200.0000

M104 S193.0000

M104 S185.0000

M104 S193.0000

M106 S255

I assume this is start of the object....h

(begin layer 1 at 0.060)

G1 X69.4300 Y137.6500 Z0.2000 F10500.0000 E0.0000

G1 X71.0576 Y136.1885 Z0.2000 F10500.0000 E0.0000

G1 X71.0576 Y136.1885 Z0.0800 F1200.0000 E0.0000

Thanks a lot in advance and any help would be really appreciated.

greengecko

[greengecko 8]

Hi, me again,

Just a question, as the error mentioned above. Could it be possible that the baud rate (which seems to be set to 250000 in the new firmware) is causing this problem?

If so how can I set the baudrate (do I have to compile my own firmware?)

Thanks again,

greengecko

[mr_seeker 0]

The baud rates are as follows:

5D firmware: 57600

Sprinter/Marlin: 115200

Printrun/Cura: 250000

You can better stick with repG or printrun instead of netfabb, but if you set the baud rate to the following in netfabb it will print.

[greengecko 8]

Hi everyone,

Thanks to all of you who read the problem description I think I have solved the puzzle. It had nothing to do with the firmware update (I suspected that because the problem occurred shortly after).

My main problem was that this problem at the start was not really reproducible and Cura/print run did print just fine. So what happened and I stupedly did not realised that, was that somehow the endstop was hit sometimes during the start gcode (netfabb is having its runin very close to the edge of the build platform. If this happened the nooze seem to loose the knowledge on its position and therefore it started at the wrong position. Still not sure why this causes a complete stop by I hope this was the problem.

I readjusted the endstop and now it prints great as before.

Thanks again for your kind support and patience,

greengecko

[Daid 306]

What happens when you hit an endstop is that that movement is canceled. Not just the moment in the direction of the endstop, but the whole movement. Hitting an endstop is to protect your machine, but should never happen during normal printing.

If you are printing very large objects where the head needs to touch the endstop, then you can use the "endstops only for homing" option in the firmware. But you'll need to build the firmware yourself then from:

http://daid.eu/~daid/marlin_build/

 

[greengecko 8]

@daid

Thanks for the kind explanation. I will try to compile my own Marlin version once my Ulticontroller arrives (I think I need anyway as SD cards are not natively supported). So far I was quite happy with the marlin firmware (nevertheless I will check next time for the differences once a new release candidate comes up) and there are so many other things I have to learn first....

Cheers, greengecko

[Daid 306]

I will try to compile my own Marlin version once my Ulticontroller arrives (I think I need anyway as SD cards are not natively supported).

The Cura RC2/3/4 firmware supports the UltiController out of the box. And I think the RepG34 firmware also does this.

[mr_seeker 0]

I will try to compile my own Marlin version once my Ulticontroller arrives (I think I need anyway as SD cards are not natively supported).

The Cura RC2/3/4 firmware supports the UltiController out of the box. And I think the RepG34 firmware also does this.

I can confirm that Marlin 1.0 natively supports the UltiController.