Cartesian printer goes to X/Y max and prints a blob

I have a printer that has been solid and reliable as can be. It is a custom designed standard Cartesian where the bed moves in Z only.
This printer has worked great for two years now and dozens of spools of filament.

My setup
Rambo controller, with a RepRap Full Graphics Controller and a fan that cools the drivers.
Marlin 1.1.8 firmware
Octoprint 1.3.10
Using CURA 3.6 <<< this is the only thing that was re-configured.

Symptoms
The head moves to X and Y max and prints. It looks like Z was advancing, but of course what I get is a pile of filament extruded in that one place. The X and Y steppers are not moving, no belt skipping is occurring. This continues until I hit the "kill" button and reset the board. If I resend the file, everything is fine.

Events that occurred just before this started happening
I recently replaced my hot end with another custom setup with a different extruder and needed to reconfigure my CURA settings.

I made a mistake in a "end of print" gcode script and instead of telling the printer to move up 5mm and home the head, I left out the G91 (relative mode) which of course then told the head to move to 5mm. Right through a print that was 25mm tall. This of course buried the hot end in the plastic, which was well adhered to the bed, which prevented the G28 from working. This would have stressed all three movement steppers for obvious reasons. I found this out a couple of hours later when I returned from a soccer game.

This sequence of events makes me think that I have toasted my stepper drivers on the Rambo board. It puzzles me that they work fine, sometimes. I would expect them to not work at all or poorly, all of the time. This printer is very solidly built, so that belt skipping and ball-screw lockup would have been VERY noticeable at the driver I expect. Because I changed nothing else but a new printer profile (that I botched), there is little chance of any other configuration issue.

Before I drop much $$ on a replacement Rambo controller (I love this board), can anyone find fault with my analysis of the likely failure cause and sad repair? I am not equipped to replace the stepper drivers soldered to this board, so it looks like a full board swap at this point.

Has anyone else experienced this kind of failure behavior and can you confirm my diagnosis before I give up $$ as a sacrifice to the gods of dumb@ss?

thanks,
DLC

---

Kits: Folgertech Kossel 2020 upgraded E3Dv6, Anet A8 upgraded E3Dv6, Tevo Tarantula enhanced parts and dual-head, TronXY X5SA Pro(E3DHemera).
Scratch: Large bed Cartesian, exchangeable heads, Linear slide Delta, Maker-Beam XL Micro Delta, 220x220CoreXY.

Is it possible to upload a fresh new firmware? Maybe the flash memory was partially reset or damaged? Reset the storage eeprom as well.

If it works manually controling the x and y axis it may be a different problem. Do you have some old gcode that worked previously? If so, try to find the problem aree by copying the old to new fils line by line and testing the gcode.

Other than that, yep I agree to replace the board. If it does the same thing, you'll at least have a backup board to rules things out.

---

--
Kind regards
Imqqmi

NFAN CoreXY printer:
[reprap.org]

Quote
imqqmi
Is it possible to upload a fresh new firmware? Maybe the flash memory was partially reset or damaged? Reset the storage eeprom as well.

If it works manually controling the x and y axis it may be a different problem. Do you have some old gcode that worked previously? If so, try to find the problem aree by copying the old to new fils line by line and testing the gcode.

Other than that, yep I agree to replace the board. If it does the same thing, you'll at least have a backup board to rules things out.

Well, what is interesting is that I can do a print, it goes sideways like I wrote. I then kill the print, power cycle the board or reset it, reconnect to Octoprint and send the exact same gcode to the printer again, and this time it works flawlessly. I am not doing anything fancy and have the EEPROM disabled, so my configuration source rules on my printers.

I remain puzzled, and have ordered a new Rambo. While the printer is down it is getting a big change. The original design used 36 tooth pulleys that only have 40 steps/mm. I am revamping to 20 tooth pulleys to double that resolution. This gives me something to do while I wait for a new board I guess. Hopefully this improves the printer in a number of ways... I know! I can move to the newest version of Octoprint and CURA 4.0 so EVERYTHING can be different when I try the next print!
Yeah, no.

Thanks for the input!

Oh well,
DLC

---

Kits: Folgertech Kossel 2020 upgraded E3Dv6, Anet A8 upgraded E3Dv6, Tevo Tarantula enhanced parts and dual-head, TronXY X5SA Pro(E3DHemera).
Scratch: Large bed Cartesian, exchangeable heads, Linear slide Delta, Maker-Beam XL Micro Delta, 220x220CoreXY.

And here I thought that I knew what was going on...
Again:
CURA 3.6
Marlin 1.1.8
Octoprint 1.3.10
and now
Simplify3D 4.1.2

I just spent 6 hours using S3D without a single glitch on about a dozen models both over USB from the computer and through Octoprint.

The very first time I used CURA 3.6 over Octoprint, it failed. The printer stopped getting commands from Octoprint it appears. I tried going through CURA to cancel the print and move the head up (or bed down, as it were) and nothing. The printer responded to front panel commands, so the F/W was still working.

So, this problem is all about CURA and Octoprint, not my controller and possibly not my firmware. However I cannot completely rule the F/W out.

I have now had weird problems using CURA and Octoprint on three of my printers. I am considering the value of ditching CURA altogether, but I REALLY love tree supports for printing gaming figures. Even S3D's excellent supports are not as good for complex models.

Now trying CURA gcode direct from SD card to see what happens. Using the same model that barfed doing CURA -> Octoprint.
I will report results.
EDIT ONE:
The SD card print of the CURA 3.6 gcode was flawless. So, something in the CURA->Octoprint->Marlin is going sideways. The S3D->Octoprint->Marlin works fine (SD card always prints better, but that is a known Octoprint issue unrelated to this problem.)

EDIT TWO:
Second SD card print experiment from CURA 3.6 failed. The print started out by wandering off to the extreme X/Y position, just like the original error through Octoprint. NOW it looks like either CURA or Firmware! The fun never ends! I guess I'll replace with my new (ack!) Rambo board and see what happens.

EDIT THREE:
I have not yet replaced the Rambo controller, because...
Huh. I now have another several hours on my printer using S3D over Octoprint, with no problems at all. But CURA 3.6 will cause a barf either through SD card or Octoprint, but only on this printer. CURA 4.0 caused the "wander off the end of the bed" error through Octoprint on another printer a couple of weeks ago, so I backed off of 4.0 until it was more polished. But I have hundreds of hours of CURA 3.4 and 3.6 on my printers with no problems. All of this from the same Windows 10 laptop. These errors occur on my Cartesian even with the latest Octoprint, regardless I will update my other Octo setups just in case. There is something that I am missing that should cause all this to start making sense, but I have not found it yet.

Hmmm,
DLC

Edited 3 time(s). Last edit at 05/27/2019 02:15PM by dlc60.

---

Kits: Folgertech Kossel 2020 upgraded E3Dv6, Anet A8 upgraded E3Dv6, Tevo Tarantula enhanced parts and dual-head, TronXY X5SA Pro(E3DHemera).
Scratch: Large bed Cartesian, exchangeable heads, Linear slide Delta, Maker-Beam XL Micro Delta, 220x220CoreXY.