Bugs/annoyances in Cura and in UM2 firmware

[axsdenied 0]

Few small annoyances in Cura:

Cura 14.12.1 (debian, amd64 and also Windows 7 32 bits):

- Open STL file

- Change view to Layers

- Clear platform

- Open STL file (same or different)

The view is empty. Cura will calculate time etc, can even save gcode file but nothing will be shown until the view is changed to normal again. I can even change the printing parameters but still no preview until the view is changed.

Another one (linux only):

- From the main window pick any option to open a sub-window, for example open retraction settings.

- Move the retraction window and position it so that it is overlapping the main window.

When you finish the move and release the mouse button, the sub-window will pop behind the main window.

This is quite bad especially if the main window is maximised to full screen as the sub-window will completely disappear.

Another one (linux only):

- Using tabs to move between options does not work properly. Open retraction window and try moving using tab. It gets "stuck" on "Enable combing".

Firmware 14.12.1:

- Start printing a large model. I was printing a 200x200 mm enclosure.

- While 2nd (or 3rd) layer was printing (solid) I noticed that one corner was lifted off and I aborted the print.

It took almost one minute for the printer to actually stop as it had to finish few lines which were quite long. Nozzle went down from 245 degrees (Colorfabb XT) to 130 degrees when the printer finally stopped trying to print.

Of course printing solid plastic does not work and there was lots of clicking from the feeder stepper motor and the filament was completely ground.

If possible the firmware should be changed to wait until the printing queue is empty before starting to cool down nozzle.

No such problems on smaller models as the printer aborts quicker.

 

[pm_dude 27]

Hi axs,

If you want to can try the beta

http://umforum.ultimaker.com/index.php?/topic/9348-getting-close-to-that-release-1501-rc11/

We are now at RC11 for the next release and many things have been changed.

 

Firmware 14.12.1:

- Start printing a large model. I was printing a 200x200 mm enclosure.

- While 2nd (or 3rd) layer was printing (solid) I noticed that one corner was lifted off and I aborted the print.

It took almost one minute for the printer to actually stop as it had to finish few lines which were quite long. Nozzle went down from 245 degrees (Colorfabb XT) to 130 degrees when the printer finally stopped trying to print.

Of course printing solid plastic does not work and there was lots of clicking from the feeder stepper motor and the filament was completely ground.

If possible the firmware should be changed to wait until the printing queue is empty before starting to cool down nozzle.

No such problems on smaller models as the printer aborts quicker.

 

Yeah that seems to be an important one. The buffer need to be finished before getting the abort command but it should be the case for the temp too. That sucks. I dont know if that one was looked into.

 

[axsdenied 0]

Will try the new version. Thanks.

Is this forum a good place to report bugs and ideas?

 

[woofy 12]

This has been reported long ago.

http://umforum.ultimaker.com/index.php?/topic/4337-abort-delayed-response-problem/?p=36245

[tinkergnome 927]

...

The buffer need to be finished before getting the abort command

...

 

I think, this is the main issue - it should not be necessary to complete all the buffered commands - because we want to abort anyway...

David has commented this long ago:

 

...

I tried clearing the buffer, however, I ran into odd synchronization bugs. So I opted to leave the buffer alone on abort.

...

 

Perhaps the firmware runs into problems because the printer is not longer aware of its current position after a "quickstop" (which clears the buffer).

Someone ( :rolleyes:) should investigate this a bit further....

Another quote :cool: :

 

(...But, so little time, so much to do...)

 

 

[Daid 306]

Someone ( :rolleyes:) should investigate this a bit further....

 

Just hit me. What we can do is add a M401 command which clears the planner buffer. And then queue this command on abort. As this command is ran from the "process_commands" loop, it should not have the sync problems that the current abort has.