Issues with FW 3.0.6RC  

Re: Issues with FW 3.0.6RC

Dear Sandro.

Thanks for relaying your findings to us.

> -The menu occasionally switches language on me, not sure to what, but the last line includes the word "tot".

This is an interesting issue I never heard of. I surely trust you it happens though. What language are you using?

> - move axis via the menu isn't accurate (at least for z, but probably others). Jog up to top, come back to 5mm, and I've gone past crashing into the bed by more than 5mm. I think I experienced this on X also, but I can't confirm at the moment.

I will try to reproduce this case. That should be easy to reproduce, if it is a systematic problem.

> - The system seems to be losing adding steps in general. One of my prints tried to move the y-axis forward on completion, and ran out of room at 191mm, but the job did the initial z-calibration well.

Do you run your printer in the silent or power mode? If you are running your printer in a silent mode, please switch to the power mode. The power mode changes currents of the X and Y motors significantly, but there is no change in current of the Z axis motors, so it will likely have influence to skipped steps in the XY plane only.

Losing steps is a tough problem to reproduce. The problem may be due to an interplay of component tolerances, so it may be difficult to reproduce to us. It would therefore help us to diagnose the problem, if you could kindly perform some tests to us.

What firmware version did you use before you upgraded to 3.0.6-RC2?

Are the skipped steps in the Z axis easy to reproduce when moving the axis up and down from the menu?

If you downgrade the firmware to the previous version, could you reproduce the problem with the skipped steps in the Z axis, or does the problem disappear?

Thank you,
Vojtech

Re: Issues with FW 3.0.6RC

Dear Sandro.

Thanks for relaying your findings to us.

> -The menu occasionally switches language on me, not sure to what, but the last line includes the word "tot".

This is an interesting issue I never heard of. I surely trust you it happens though. What language are you using?

Actually, it's just the main screen that is switching language, the other screens still appear in English. I normally use English.

> - The system seems to be losing adding steps in general. One of my prints tried to move the y-axis forward on completion, and ran out of room at 191mm, but the job did the initial z-calibration well.

Do you run your printer in the silent or power mode? If you are running your printer in a silent mode, please switch to the power mode. The power mode changes currents of the X and Y motors significantly, but there is no change in current of the Z axis motors, so it will likely have influence to skipped steps in the XY plane only.

I had suspected this, so I switched to high power mode. Funny thing it that it sounds the same as silent mode. I reverted to 3.0.3, and tried them both, and X/Y are noticeably louder in that version. I will switch back to 3.0.6 and confirm that I'm not hearing a difference between them.

Losing steps is a tough problem to reproduce. The problem may be due to an interplay of component tolerances, so it may be difficult to reproduce to us. It would therefore help us to diagnose the problem, if you could kindly perform some tests to us.

What firmware version did you use before you upgraded to 3.0.6-RC2?

Are the skipped steps in the Z axis easy to reproduce when moving the axis up and down from the menu?

If you downgrade the firmware to the previous version, could you reproduce the problem with the skipped steps in the Z axis, or does the problem disappear?

I originally used 3.0.3, but upgraded to 3.0.5RC only 1-2 days after receiving the printer. I used 3.0.5 for about 1 week before 3.0.6

Too many or inaccurate steps in Z seem easy to reproduce, I was just tramming up and down to confirm that both z-motors were moving the same amount (I had a couple of nozzle crashes doing x/y calibration). After quickly moving the carriage to the top, then back down again, the nozzle crashed into the bed, even though the menu claimed I was still well above 0mm. The same thing occasionally happened moving up. I started at home position, and crashed into the top even though the menu though I was at <190 millimeters or so..

I've already downgraded to 3.0.3, so I will try to reproduce using this version. I'll try 3.0.5 after a bit on 3.0.3.

Re: Issues with FW 3.0.6RC

Sandro

I think you are misunderstanding the Z alignment.

If you home the Z axis, the nozzle and firmware will both be set to 0.15mm

You then move the Z axis up to the top stops; this requires the Z axis to move approximately 205mm, but the firmware allows for a variation here and will drive the motors to 210mm.

If the Z axis has stopped at 205mm and the firmware continues to drive the motors to a position where the firmware believes the Z axis is at 210mm, the firmware will think the Z axis is 5mm higher than it actually is.

So, if you then lower the Z axis 210mm, the nozzle will actually be 5mm below the surface of the bed. You should not do this. What you should do is to lower the Z axis a small amount and then use the "Auto Home" option to get the Z axis back to where it needs to be.

Peter

Re: Issues with FW 3.0.6RC

Do NOT enter the "Support ->" menu; especially if you are printing. The printer will slow down considerably. 😕
The Progress bar is back while USB printing! 😀
Live Adjust Z disappears and reappears randomly while USB printing 😥

I also have experienced more failed prints with 3.0.6 due to the fact that the Z axis appears to either not shift up far enough or shifts down when doing large prints. This has caused the nozzle to crash into my print lifting it from the print bed multiple times. I'm currently using 3.0.5 because it doesn't suffer from this issue as much and 3.0.3 causes my PEI sheet to get damaged when I start a print due to head crashing into the bed (this is the 2nd time I've had to replace my PEI sheet).

I am planning on replacing my 3 Linear bearings on my Y axis in case I've worn them out over the course of a month that I've used the printer. I will have this done by the end of this coming up week.

Re: Issues with FW 3.0.6RC

Ayork

I am running 3.0.6 and I have not seen any of what you describe.

When printing, I have no reason to touch the printer (I use OctoPrint via USB), there is absolutely no need for me to use either the support menu or live Z adjust. Of course, I have now noticed that the progress bar is back.

Currently I am printing large parts of a Taj Mahal model:

This is the fourth such part I have printed consecutively without touching the printer, other than to remove the parts.

Peter

Re: Issues with FW 3.0.6RC

Sandro,

> Too many or inaccurate steps in Z seem easy to reproduce, I was just tramming up and down to confirm that both z-motors were moving the same amount (I had a couple of nozzle crashes doing x/y calibration). After quickly moving the carriage to the top, then back down again, the nozzle crashed into the bed, even though the menu claimed I was still well above 0mm.

There is a bug in the Marlin firmware and the MK2 firmware is based on the Marlin firmware. If you move any axis up and down, left and right etc quickly many times, there is a queue in the firmware, which quickly overflows. This will be fixed in the 3.0.6 final. This problem has nothing to do with skipped steps during the print.

Vojtech

Re: Issues with FW 3.0.6RC

Wow, Peter brilliant looking print. Please show finished Taj Mahal when you can. Wonderful print.

Re: Issues with FW 3.0.6RC

[OFFTOPIC] Peter what material is that Taj Mahal print? And what is the Etanol bottle for? Are you cleaning bed with Etanol? Thanks

Re: Issues with FW 3.0.6RC

[OFFTOPIC] Peter what material is that Taj Mahal print? And what is the Etanol bottle for? Are you cleaning bed with Etanol? Thanks

Luis

I print mostly with PLA (this model is PLA). The Ethanol is the Slovene equivalent of Isopropyl Alcohol 😀 It cleans the bed rather well and has a couple of other uses 😈

I had a problem when printing that particular part. The part fan stopped working, so the model is not a good as usual; I will clean up the strings before I assemble the model.

Peter

Re: Issues with FW 3.0.6RC

Sandro,

> I had suspected this, so I switched to high power mode. Funny thing it that it sounds the same as silent mode. I reverted to 3.0.3, and tried them both, and X/Y are noticeably louder in that version. I will switch back to 3.0.6 and confirm that I'm not hearing a difference between them.

I verified, that the 3.0.3 and 3.0.6 firmware behave identically when setting the motor currents.

Vojtech

Re: Issues with FW 3.0.6RC

To Sandro:

> -The menu occasionally switches language on me, not sure to what, but the last line includes the word "tot".
> Actually, it's just the main screen that is switching language, the other screens still appear in English. I normally use English.

Would you please expand on that? So it is only the status screen, which switches a language? To which language? Would you please post a screenshot? Does it happen during the print? Do you print from USB or from a SD card? If from USB, what application are you using to communicate with the printer?

> - The system seems to be losing adding steps in general. One of my prints tried to move the y-axis forward on completion, and ran out of room at 191mm, but the job did the initial z-calibration well.

...

> I had suspected this, so I switched to high power mode. Funny thing it that it sounds the same as silent mode. I reverted to 3.0.3, and tried them both, and X/Y are noticeably louder in that version. I will switch back to 3.0.6 and confirm that I'm not hearing a difference between them.

I verified that the 3.0.6 printer uses the same motor current settings as 3.0.3 firmware. There are some differences in acceleration, jerk and path planner settings, which may make the 3.0.6 firmware sound smoother. I don't have a better explanation right now.

To ayourk:

> Live Adjust Z disappears and reappears randomly while USB printing 😥

We are hiding the Live Adjust Z menu when the Z axis is above 0.5mm. The Live Adjust has its purpose to adjust a squish of the first layer.

> I also have experienced more failed prints with 3.0.6 due to the fact that the Z axis appears to either not shift up far enough or shifts down when doing large prints. This has caused the nozzle to crash into my print lifting it from the print bed multiple times. I'm currently using 3.0.5 because it doesn't suffer from this issue

What application are you using to prepare your print? Slic3r? Simplify3D?

We are having some issues internally with the G-codes generated by Simplify3D. We are not quite sure what causes the problem, but surely Simplify3D performs the layer change differently from other slicers. It first moves the print head in the XY plane to the new spot and then it moves the Z axis up. We solved our problems by putting G4 code before each Z lift line (line starting with G1 Z). We will update the Simplify3D profile to generate G4 (pause and flush the planner queue) before Z lift automatically. Other than that, we have a bunch of testing printers and we have a large print farm running 24/7, and we do not experience skipped Z steps with G-codes generated by Slic3r or G-codes generated by Simplify3D with a G4 code before Z lift.

It is true that I changed the path planner in the firmware between 3.0.5 and 3.0.6 exactly for the reason of solving apparent skip steps in the Z axis when printing G-codes generated by Simplify3D. We also lowered the jerks and accelerations on the Z axis in 3.0.6 firmware. I personally am not quite convinced that the problem is in the Z axis only. It may be as well the quick XY move generated by Simplify3D before Z lift, which digs through the top layer, which may ruin your print.

Please let us know if you have a better explanation.

Thanks guys for your update,
Vojtech

Re: Issues with FW 3.0.6RC

You are correct. Simplify3D is the only slicer I use. Any chance you can provide a screenshot of where to apply the G4 command?

Re: Issues with FW 3.0.6RC

Ayork

Sounds as though you will have to edit the GCode with a text editor (such as Notepad++) and insert it as Vojtech has advised.

Peter

Re: Issues with FW 3.0.6RC

I am happy to hear that the apparent skipped Z steps are caused by the Simplify3D software. Well, I don't want to put the blame on them, but somehow our printers do not like the code they generate.

Please try to enter the snippet in the screenshot into Slimplify3D. I would be happy, if you come back with your results.

The generated G-codes shall contain G4 before each Z axis movement after the Post Processing snippet is entered. It will slow down the print somehow if the Z hop is active though.

We will update the Simplify3D profile soon.

Vojtech

Re: Issues with FW 3.0.6RC

Sandaro,

> The menu occasionally switches language on me, not sure to what, but the last line includes the word "tot".

It is quite possible, that this error is a result of a stack overflow when you exercise the axis movement from the menu. Sometimes the firmware crashes, sometimes it is left in an inconsistent state. Then everything is possible. As already stated, the stack overflow error on axis movement from menu will be fixed in 3.0.6 final.

I would still be happy, if you please could confirm, whether the random language switching or the "tot" bug appeared when you printed over USB. This is a use case we don't test so much as printing from a SD card.

Thanks, Vojtech

Re: Issues with FW 3.0.6RC

Does the z axis step drop problem effect the older version of the firmware?

Re: Issues with FW 3.0.6RC

I am happy to hear that the apparent skipped Z steps are caused by the Simplify3D software. Well, I don't want to put the blame on them, but somehow our printers do not like the code they generate.

Please try to enter the snippet in the screenshot into Slimplify3D. I would be happy, if you come back with your results.

The generated G-codes shall contain G4 before each Z axis movement after the Post Processing snippet is entered. It will slow down the print somehow if the Z hop is active though.

We will update the Simplify3D profile soon.

Vojtech

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.

Also, I'm interested in your replies to my PMs about Arduino and RC3.

Re: Issues with FW 3.0.6RC

Sandaro,

> The menu occasionally switches language on me, not sure to what, but the last line includes the word "tot".

It is quite possible, that this error is a result of a stack overflow when you exercise the axis movement from the menu. Sometimes the firmware crashes, sometimes it is left in an inconsistent state. Then everything is possible. As already stated, the stack overflow error on axis movement from menu will be fixed in 3.0.6 final.

I would still be happy, if you please could confirm, whether the random language switching or the "tot" bug appeared when you printed over USB. This is a use case we don't test so much as printing from a SD card.

Thanks, Vojtech

I have also seen this. It only seems to happen when moving the axis from the menu. I can reproduce at will.

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?

You may try to escalate the issue to Simplify3D. What they do is they first move the print head rapidly in the XY plane digging into the top of the print exadurating the risk of knocked off prints, then first they lift the Z axis up. They believe this is the proper way to do because lifting the Z axis first produces blobs on the outer perimeter in some FDM printers. So they don't want to change that. They recommend to use the Z lift on retract and retract on layer change, which surely solves the issue of knocking off the prints due to the nozzle digging into the top layer, but it does not solve our Z axis issue.

The issue we are facing is probably a jerk of the X axis after a long rapid XY move halts to lift the Z axis up. Then the jerk of the X axis translates to the Z axis. The Z axis is a lot weaker than the X axis and the Z axis carries the weight of the X and Z axes combined. So if you hit the Z axis with a hammer, it needs a bit time to stabilize before it could be moved up. We don't see this effect with Slic3r, because it plans the paths differently.

I did some changes in the path planner between 3.0.5 and 3.0.6 since I was not aware of the effect and I was worried how the original Marlin firmware combined jerks of different axes. The code in Marlin was certainly not clean. It is possible, that the S3D issues we are facing were worsened in 3.0.6 a bit, but we at our print farm were having the issue with the G-codes generated by the Simplify3D and the 3.0.5 firmware as well. Now the G4 code instructs the path planner to stop to halt and to wait some milliseconds, which seem enough for the X/Z axes to recover from the X jerk and our prints in our print farm are fine now.

With this knowledge, I will probably try to solve the combined X/Z jerk in the firmware, but not in 3.0.6. As of today, only the G-codes generated by S3D seem to cause problems and the post-processing script in S3D seem to solve it.

Vojtech