Head hitting bed with initial calibration and print after update to 2.0.4

[thesec]

After having updated to 2.0.4 the initial calibration ended with the bed being moved higher than the heads and the left head crashing into it. The second try - after having restarted the printer - worked flawlessly.

But the first print repeated the initial behavior of the head crashing into the bed for it being moved to high. Turning the printer off and back on ... the second try of the print - just when I was ready to record a video for you guys - worked.

Is this a known or familiar issue? Perhaps related to https://github.com/BCN3D/BCN3DSigma-Firmware/issues/114?

[AlejandroGarcia92]

I don't have an answer right now, it's strange but we will investigate it.

[thesec]

Thank you. It might be a coincident only. I will verify on the hardware end of things, too.

[thesec]

Btw - the bed hits the end-stop first (so the end-stop is working), is then lowered, then the nozzle is primed before the bed goes up just slightly below print height. The latter is where it goes up too high then, right before printing.

[Valenthior]

After the update, mine has gone into endstops... I had to turn it off as the motors were forcing (I do not know whichone). Turn it on again and made a Z calibration which went flawlessly.

[AlejandroGarcia92]

Understood.

[thesec]

Trying to get a photo or video it printed well for a single print just to move the bed directly into the head prior the next, see attached photo. The endstop has not been hit before to get the level, instead the bed just moved up and into the parked head ... exactly the same as with the first run of initial calibration. Seems like the z-leveling routine is skipped :/

[AlejandroGarcia92]

I remember something like that and I fixed changing the endstop in that case. It was also random, it didn't always hit the bed.

That's strange because we don't have any problem with that.

[thesec]

Thank you and yes, I agree that being strange :) ... appreciating any thoughts this thread brings up on either helping to detect a hardware or software issue ...

In the last case - the one I added the photo for - the bed level was not detected hitting the endstop first but the head was left in place (homed after previous print) and the bed immediately moved up.

So the regular pre-print routine moving the head to the middle of the bed and the endstop on top of it - prior the bed starting to move upwards - was being skipped. Could this happen when the endstop signals being hit all the time? Other? There's no check for the endstop being released?

[AlejandroGarcia92]

The same issue has happened today on one of our Sigmax and I fixed by connect and reconnect the flat cable. It seems that is a bad connection issue in my case. Also, depends of the position of the carriage there was a good connection or not.

[thesec]

Oh, which cable has it been in your case?

[AlejandroGarcia92]

The cable that is connected to the right "hotend board" in my case.

[thesec]

Wow, the one one would guess for lastly ... how did you identify this cable as "the one"?

[AlejandroGarcia92]

I checked the connections between the MainBoard and the endstop, there are 2 elements between: a flat cable and the hotend board. In my case, the problem was on the right Z endstop, so I only checked the right.

[thesec]

So I guess your's was hitting the right head upon head's calibration?

[AlejandroGarcia92]

Yes

[thesec]

Thanks Alejandro, retried with 2.0.5 and new wiring (X and Y) and drivers (X). While the calibration went fine the first print after unloading and loading new filament showed the same behaviour: the left head was just moved aside on X and the bed then started to move into it, the move on Y was missing to move the endstop over the bed.

I will retry after a downgrade to 1.2.7 ... the guess being that that'll either keep it and will get a new driver on Y or no longer show it - as before - and indicate a firmware issue ...

[thesec]

Am happily back printing after a downgrade to 1.2.7.

So - to me at least - it seems like there's obviously a bug in the pre-print bed level detection missing out the move on Y with 2.0.4 and 2.0.5 at least :/

Let me know if I can help you narrowing it down.

[AlejandroGarcia92]

Ok

[amosharchi]

Greetings, I just want to concur that I have the exact same issue.

Originally an R16 model, with the LCD screen that has the white frame, not black, upgraded to R17 with the new smart fan upgrade, and the new 6 stepper motor quieter controllers.

The upgraded required me to update to the newest firmware (and LCD update), I was skeptical that I did something wrong with the procedures, not connecting some hardware properly, or with something grounding with the frame, but seeing the thread is great news for me actually.

I resolved my issue by basically skipping the left extruder z-axis calibration, and doing the rest of the (not so full anymore) full-calibration, only to manually fine-adjust it later separately.

To summarize my case: ONLY during the full-calibration routine, and sometimes during the assisted bed-leveling routine, but never during printing (so far), the end-stop trigger for the left extruder (specifically, I didn't notice it for the right) doesn't function as expected.

By that I mean the bed raises until it reaches the trigger, and simply stops at the peak, where a slight lowering is expected, which is a location higher than the nozzle, the print-head parks on the side, extrudes some filament , if it's the z-calibration routine, or the machine instructs me to adjust the two knobs if it's the assisted bed-leveling routine, and then the nozzle crashes into the glass-bed.

[thesec]

Thanks for adding your repro case, @amosharchi. Did you use the display's firmware files as provided or did you compile your own?

[amosharchi]

Thanks for adding your repro case, @amosharchi. Did you use the display's firmware files as provided or did you compile your own?

The ones provided LCD-FW version: 2.0.2

[thesec]

Thanks again :) So that should exclude my own display fw compilation from the equation. At least it is not common between the two printers.

[amosharchi]

Thanks again :) So that should exclude my own display fw compilation from the equation. At least it is not common between the two printers.

You're welcome, in any case, I hope this gets resolved soon, as I'm planning to upgrade to R19 soon, in which case downgrading to an older firmware as you did won't be an option if I'm not wrong.

[thesec]

Should you mean to install the upgrade kit by "upgrade to R19" including the Bondtech's etc. that will not block you from downgrading (actually have all but the filament runout sensors on mine). You'll only need to update the extruder's step settings manually if you do. For the filament runout sensors you'll need to change and recompile the printer's fw.

[amosharchi]

Honestly I don't know how to manually adjust the extruder step settings, nor how to change and recompile the printer's fw, so you just confirmed to me that I cannot rollback from R19 to an older firmware haha.

[thesec]

I guess your perspective applies to most Sigma customers. The more important it is to get this blocking issue out of the way :)

[AlejandroGarcia92]

@amosharchi the steps can be modified via serial communication even gcode file.

Anyway, did you contact support? Because, since 2.0.2 fw was released, we received a lot of inputs such as lcd issues, etc..., but not something like that. Obviously, there is something happening extra that are not working properly because the new machines and the majority shouldn't be work fine.

Another customer had a strange issue #200 and he fixed it by disabling the filament runout sensor.

There is another thing that can be done but it's necessary a programmer to reload the mainboard bootloader, it does a full reset. I don't believe in that solution btw.

[thesec]

Perhaps the filament sensor's switch not being wired up properly. Neither amosharchi nor me do have one installed so there won't be any relation to that.

What exactly does it require to reload the mb's bootloader?

[AlejandroGarcia92]

Theoretically is well wired despite the robustness which is the issue itself. So, the filament runout sensor button exists in case of the sensor is not working properly, you are able to disable it and still using the printer. In addition, the cause can be the plat wire, driver or mb.

We use the AVR-ISP-MK2 programmer, but maybe it is not the solution. We did a full reset always when a printer arrives to the technical service just in case.

[amosharchi]

@amosharchi the steps can be modified via serial communication even gcode file.

Anyway, did you contact support? Because, since 2.0.2 fw was released, we received a lot of inputs such as lcd issues, etc..., but not something like that. Obviously, there is something happening extra that are not working properly because the new machines and the majority shouldn't be work fine.

Another customer had a strange issue #200 and he fixed it by disabling the filament runout sensor.

There is another thing that can be done but it's necessary a programmer to reload the mainboard bootloader, it does a full reset. I don't believe in that solution btw.

Greetings,

How can I modify the steps in the GCode via USB Serial communication?

I'd also would like to note that sometimes this doesn't happen when doing a calibration, and there's also an update, the same bug occured recently with a print-job, in the beginning while homing all axis, so I don't think the calibration script is faulty.

I just reset the printer, restarted the print-job, and all is fine, it's printing now without a problem.

The update is that it seems to be random, and not isolated to a certain routine (full-calibration of bed calibration)

However, this print-job gcode was created by Simplify3D, their Starting Script isn't very reliable compared to Cura, so it could be a mixture of two issues, but I'll try to configure the calibration gcode via serial communication anyway.

[thesec]

See e.g. page 12 of the manual from emvio engineering on the gcodes required to change the extruder steps, @amosharchi: https://emvioeng.com/wp-content/uploads/2017/06/Bondtech-BCN3D-Sigma-installation-V2.pdf

[thesec]

And yes, the issue is not 100% reproducible but the effect is always the same and damaging the mechanics, therefore blocking the affected machines from being updated to 2.x. This is not related to S3D or any other slicing software @amosharchi.

[thesec]

@AlejandroGarcia92 - will this adapter do to allow me resetting the mb? https://www.amazon.de/MUZOCT-Programmierer-Adapter-ATMEGA8-ATMEGA128/dp/B075SYQXCP Which software is required to apply the bootstrapping?

[AlejandroGarcia92]

We have this programmer Olimex AVR-ISP-MK2, I don't know if we buy it at farnell or somewhere cheaper. I need to look for software to do that job in an easy way (I use a Rapsberry pi or AtmelStudio right now). @thesec I think that your programmer will not work.

[AlejandroGarcia92]

@amosharchi

You would need to execute the following commands:

M92 E492.45   ;set steps per mm
M203 E40       ;set max feedrate
M500            ; save

If you need to set the default values execute M502

In the new FW, there is a menu to change those parameters.

[thesec]

Does it require the 10 or the 6 pin connector @AlejandroGarcia92 ?

[AlejandroGarcia92]

We use the isp10 port but we convert it to 6 using a converter 10 to 6. We use a converter 10 female to 6 male but it's more common to find a 10 male to 6 female. I attach you 10 pictures below.

[AlejandroGarcia92]

@amosharchi I recommend you, anyway, to contact with support because they have a lot of feedback.

[thesec]

Thank you for the details on connecting the programmer, @AlejandroGarcia92. Just ordered one to see if that'll allow me to update my upgraded Sigma. How do I bootstrap the board once the programmer arrives? Do you have a guide at hand or could advise me how to do so?

[AlejandroGarcia92]

@thesec I have no guide, I should give you support on that. I'm trying to find a software to do it easily. However, I think that it can be done by command line too. Let me try on Monday.

[thesec]

Thanks in advance, @AlejandroGarcia92 - appreciate it a lot 👍

[AlejandroGarcia92]

I think that you will need to use AtmelStudio to burn the bootloader.

[thesec]

Downloaded and installed ... settings seem plenty ... 😳 How to do the bootstrapping with it?

[AlejandroGarcia92]

You will need to load the following .hex(inside .zip), also you can find it here.

BCN3D-stk500boot.zip

How to burn the bootloaded step by step using AtmelStudio 7:

Disconnect the sd cable from MB like this:

1-Open AtmelStudio

2-Go to Device Programming (Tools/Device Programming)

3-Select the AVRISP-mkII programmer.

4-Select the ATmega2560 device.

5-Press Apply.

6-Go to Memories and check if all setting are configured like the picture. An browse for the file .hex that is shared at the beginning.

7-Press Program

8-If Verify is ok, you have finished.

Finally check if the following led blinks. Then, reconnect the sd cable to MB at reinstall the firmware using Cura.

[thesec]

Excellent, the programmer was just claimed shipped in parallel ... can't wait for it to arrive ... 😬 Thank you @AlejandroGarcia92

[AlejandroGarcia92]

Remember to put programmer's wires and jumpers as I show you.

[thesec]

The adapter I received was for PDI only ... waiting for the ICSP one to arrive ... 😢

[thesec]

Test MB successfully reset ... next fw update and re-testing ... waiting for the prints to end :)

[thesec]

Yay ... finally hit the issue 🙈 It had indeed been a "coincidence": having installed heatinks on the motors the left one seems to have triggered the endstop every now and then. This resulted in the endstop routine to be immediately ended when starting to listen for it and hence the following leveling prior print moving the bed up further ...

The printer is now running fine on 2.0.6 :)

Thanks for your support @AlejandroGarcia92, have a good start in 2019.