gr5

You could just edit out those tiny movements circled above by hand and see if that helps. Are you using Marlin? What firmware are you using? I think at this point i would recommend you get klipper firmware. This will require hardware changes but it's worth it. Klipper is about 10 years more modern than Marlin. I guess the more important part is that it is a complete rewrite so it will have different bugs than Marlin and the guy who wrote Klipper is pretty damn smart and made very different choices (software architecture choices). The people who wrote marlin are also very smart but it runs on a very weak processor. They made some tough choices to get it to work on an arduino. Klipper doesn't have cpu restrictions and so the code is less likely to be buggy and it can handle weird gcodes better. Your issues are slightly more likely to be in travel moves (blue lines) than in extruding moves because travel moves are usually faster. Moves this short with acceleration so slow *shouldn't* move any faster but... there are a few bugs in marlin where it violates acceleration limits. Did you know there are two (two!) different max accelerations in Marlin? One is meant to be *the* acceleration in every move - it tries to always accel and deccel at that rate. The other is a "max accel" which I think is double which Marlin stays under in special circumstances. It's a big kluge. A hack. It's ugly. I forget what circumstance might make it go over the acceleration.

Well you could downgrade the firmware. Most of the updates in the last year seem to be related to Digital Factory so if you don't use DF then you might be better off not upgrading. Although some of the updates are critical if you have a printer less than a year old: because of parts shortages, some newer printers have differences that require the newer firmwares. Downgrading the firmware is usually not trivial and requires removing the bottom of the printer and preparing a uSD card. But your reseller can help you do that.

Once it says "job control turned off" that's it - it is ignoring you. Is there any way to hit enter before it says that? I'd try hitting enter every 5 seconds until you get that message. Even during the boot. I'm thinking it needs to know you are there and not "away from keyboard". Anyway I didn't have this problem so I think maybe the tty drive is somehow corrupted so it's time to install a fresh operating system. Get jessie from my web page. Search on my page for "mainline". It needs to be copied to a uSD just like you did with the Ultimaker recovery image. It would be nice if you had two uSD cards as then you don't have to recreate the ultimaker one every time you test to see if the printer is going to work.

Maybe that "can't access tty" message is a hint - maybe it won't let you type at that point. I never had that problem but I was using the S5 recovery. But still! It's the same code I think. Anyway if typing "Enter" key doesn't work, and you have hit it several times, and you can't enable this in putty... Wait try one more thing - hit enter a few times while it is booting so that it knows you are there. Maybe hit it IMMEDIATELY after the sad robot - maybe if you don't hit enter within a few seconds it decides no one is home? Is there a delay between the robot and the "can't access tty" message? If none of that works then you can get "debian jessie" image off my web page, put that on your uSD and run that. It will boot fine with no errors as it won't even try to touch the SSD. It won't even try to mount it or anything. And you can then log in. My jessie image is from olimex so there is definitely a username and password but I don't know what it is. It's probably mentioned on my web page and if not it's mentioned on the olimex site somewhere.

If you hit carriage return a few times do you get the # sign? It looks like you got the # at the very end. Hmm. Maybe this is disabled on purpose? It always worked for me. Hit the Return key while you are in putty - I mean click on putty to make sure it is the currently active application and then hit the return key 3 or 4 times. It should print out a prompt which might be as simple as ">" or "#" each time on a new line. Then you can type "help" as it says in the message. Or "df" to display information about the 'disk" devices, or any of hundreds of other linux commands. If none of that works google "putty through serial port - can't type anything". Maybe you have to change some checkbox somewhere in putty.

Look the only thing you have to do is execute this command: mkfs.f2fs /dev/mmcblk1p2 -l root which formats partition 2 on the SSD. That's it. All the instructions lead up to doing that one command. If you are lucky, the mkfs.f2fs command will just work. So all you have to do is log in (maybe not even that) and get the command prompt (probably a # symbol). Every time you hit enter it should show you the prompt. If you get that then it's ready for commands. Try the above command. If it says something like "command not found" then you have to install the formatting utility for f2fs file system and I explain that which is pretty simple except first you need to be on the internet. Which is sometimes easy and sometimes hard. So it seems like a lot of steps but the above command is all you need to do and it might just work. Probably not because my notes (on my web page) say that firmware 5.3 doesn't have it. Once the partition is formatted you can power cycle which tries firmware recovery again and should work.

I'd get the oldest version that still has the auto-partitioning which is explained on my web page.

You may think you want these recovery firmwares here: https://support.makerbot.com/s/article/1877434822572 But they have purposely hidden the S5R1 firmware because the S5R1 printer has deadly exposed voltages near where the uSD goes in so they want you to sign wavers, talk to a human, etc etc. (all you have to do is keep it unplugged while your fingers are within a meter of the printer) But I have the firmware available on my web page. And you don't want to use the newer firmwares because UM no longer uses Olimex in the newest printers. If you read my web page it explains which version of the firmware is too old for the auto-formatting and which version is new enough to have it.

on. my. web. page.

I wonder what would happen if you used the S5R1 firmware recovery on the UM3. Would it repartition and reformat before it notices it's on the wrong hardware? If that works then you can switch back to the UM3 recovery as the partitions would be all formatted by the S5R1 recovery procedure and the UM3 recovery uSD would now work. Potentially.

So here is the relevant error: Error: unable to mount '/dev/mmcblk1p2'. the 1 in blk1 is the SSD on the olimex. P2 means partition 2. I talk about this in my unbricking web page. The latest firmware for UM3 appears to be 5.3.0. This is very unfortunate!! The firmware people added code somewhere around 5.7 (for S3, S5, S7 only) that will automatically handle the above error and reformat mmcblk1p2. So you need to (as a minimum) reformat partition 2 on mmc blk1. By the way there are more errors shown but we already know the problem is partion 2. [ 12.102194] F2FS-fs (mmcblk1p2): invalid crc_offset: 64527 [ 12.108183] F2FS-fs (mmcblk1p2): invalid crc_offset: 64527 [ 12.113682] F2FS-fs (mmcblk1p2): Failed to get valid F2FS checkpoint [ 12.120707] F2FS-fs (mmcblk1p2): invalid crc_offset: 64527 So you need to format the partition. You will need f2fs. This is getting more complicated unfortunately but this is 100% the problem and similar to what I expected. What I didn't realize is that this recovery image is so old - about 5 years old maybe? And it doesn't have the better recovery code that is in 5.7.X. Anyway once it finishes printing out the sad robot, it's time to hit the Enter key on your keyboard and try to log in. If it asks for username and password, username is root and I'm not sure of password. It might not ask for either - it might be that you are already logged in. Read the stuff on my web page. I try to walk you through the steps. They aren't trivial but not too bad either. Try to jump right to the f2fs format commands. Step 5. If it doesn't know the command it means the f2fs partition code isn't installed. So you can read about apt-get. You will need your printer on the internet to use apt-get. Anyway I'm just repeating what is already written up in the unbricking document. If step 5 doesn't work go back to step 1, getting the network working so you can use apt-get to get the f2fs formatting ability. Even once you get f2fs working, it might fail the format command. Try a few times. If it won't format you need to repartition. I talk about that as well. At least you don't have to install any software to repartition!

Instead of playing with the shape of the part. go to PREVIEW mode in cura and use the horizontal (not vertical) scroll bar to play through a few layers. Maybe also set PREVIEW mode to show the speed setting as a color. THIS is where you will see something non-symmetrical. Some "weird" move that doesn't happen very often. If you can find the movement that causes you to lose a step then this gives you a huge hint. I've personally done exactly this. It's usually in the infill or travel moves among the infill or within "combing" moves within the infill. It's usually not the outer shell (outer walls) lines. Or sometimes it's on a z move possibly. Particularly buggy is if you move Z and another axis at the same time as the original programmers didn't expect this. But cura probably won't do this anyway. But it could be moves just before or after the layer change.

agreed. yes There are so many movements it's really hard to say what the problem is. Cura does different movements on layer changes - sometimes it reverses 180 degrees for a mm or more at the layer change. There are things like coasting. There are tiny combing moves there are moves with slightly changing angles like circles which are done at faster speeds, there are long straight sections that are done with faster speeds, there are corners where there may be too many points and the processor can't keep up: typically these controllers hold 16 moves in advance. If you have 16 gcodes but the printer only moves 1mm then it has to slow way way down because it doesn't know what is coming up next - possibly a sharp corner. It's just a lot to figure out. Maybe if you step through one layer slowly in PREVIEW mode you might see something strange that is in X but not Y. But really, your printer should be able to handle anything. The printer itself has firmware that is supposed to be able to handle any speed you throw at it. So the printer firmware has a max speed, max accel, max jerk. If cura exceeds those, the printer should limit them. That's why I'm blaming the printer hardware and not cura. Also if you film the printer printing one layer you will probably hear a nasty sound at the moment where a step is loss. The whole printer probably shakes more than usual at some spot. That might give you a hint as to the problem. You could use that to write custom gcode that moves the head in only X and Y at those speeds and does them in a loop and see if the print head slowly drifts in one direction. Then you could play with max accel, max speed, max jerk in your firmware and see if you can make those "crazy" moves not cause drift/skew. Or maybe you can fix it by tightening set screws in pulleys or whatever is slipping (if it's a hardware slip versus a stepper motor slip).

I entered text through putty. Start with enter key. If that does nothing then recheck the cabling. If you plug in a USB cable I think it goes to a different console than the one through putty. You would need to get the hdmi cable outputing info before plugging in a usb keyboard. I think. More information on the olimex forums.

By the way, you are doing fantastic - you got the serial cable working! Congratulations! This is a big step.

How to output everything in putty to a file: https://www.dell.com/support/kbdoc/en-us/000116043/dell-emc-networking-how-to-use-putty-exe-to-save-output-to-a-file

In putty there should be a window that is spewing out information. Well before it spits out the sad robot is valuable information. In putty, once it stops booting, you should be able hit the return key on your keyboard and it should prompt for a username (use root) and/or password (use "ultimaker" typically - also try "root" "password" or lookup on the olimex website what the recovery password is typically but ultimaker setup the root password somehow. So you can log into debian linux and there are thousands of commands you can do to look around. But more importantly save *all* of the boot process. There should be a way in putty to log all output into a file. If I remember right. I haven't used putty in about 5 years. I used to use it every day.

So when you have layer shifting like that there are a few common causes. All of them mechanical. You could be losing steps (full steps). That is fixed by increasing lubrication and decreasing acceleration and jerk. On a new machine you should be pushing accel harder and harder until you lose steps so you have an idea what the limit is. Then back off maybe 50%. Same with jerk setting. Another cause is slipping pulleys or other slipping hardware. So you can mark the shaft of every stepper and everything attached to that pulley to make sure nothing is slipping. You mark the rod and pulley with a sharpie, take a phto, then do a print, then check your markings. I know you say it's not mechanical because it moves with the part rotation. That just probably means there is some high-acceleration move related to (for example) changing layers or to the central bar where cura does 2X the speed or 2X the acceleration of typical moves. The problem is still with the hardware, not with cura. If there was a skew created by cura you would see it in the PREVIEW mode of cura.

Oh! So there *is* a way to put an image in the gcode comments. That's a new feature I've never seen before! I don't know what algorithm they use to convert an image into ascii data like that. It looks like base64 encoding. I think the 300 300 is the image size (300 pixels square) and the big number is the number of bytes or maybe characters that follow. Then it looks like base64 encoding (you can google about it) and there are utilities and web pages that convert files to and from base64 but you also have to add the comments and carriage returns and so on.

gcode files are just text files. They can't contain images. ufp files contain lots of meta information including gcode, thumbnails, and other meta information such as what printer you sliced for, what nozzles are needed, materials, etc. Maybe you mean ufp files? I think you must mean ufp files. You can definitely edit/change the thumbnail in a ufp file. Octoprint (or I guess printoid?) will display that thumbnail. Here's how you do it: rename the ufp file to be ".zip" instead of ".ufp". If you are on a windows computer it may be hiding the extensions. Google how to show file extensions on your particular version of windows. Then double click the zip file and you will see the directory struction. It's easy to find the thumbnail as there are only a few files in there - replace it with a file of the exact same name that you want to be the new thumbnail. On windows I think it's best to extract the entire ufp into a directory structure, change the thumbnail, then zip it back up with some utility. I don't use windows much lately but I think windows will zip up a folder if you right click on it? Or you can install winzip or other app that makes zip files. Finally rename the .zip extension back to .ufp. Now octoprint will show the thumbnail. My description may sound complicated but once you've done it a few times, you can change a thumbnail in about 5 seconds.

Can you just pass "retract continue" a negative number?

We must have different definition of "thumbnail". To me a thumbnail is a small photo associated with a file such that on your computer you can see a small image related to the file.

There is a setting - something like "retract on layer change". Having that checked could both cause this problem or having it unchecked could cause this problem. So try it both ways.

I'm not sure but I don't think your model is manifold. Meaning it's not solid. You have to define how thick all walls and structures are in the model. I suspect you might not be doing that in places. If you have an infinitely thin surface in blender then Cura will just ignore that surface. Google about how to make manifold models in blender. Also read about how to specify which side of every surface in blender faces plastic versus air as this information goes into the STL file as something called a "normal". More here: https://www.sculpteo.com/en/tutorial/prepare-your-model-3d-printing-blender/ Read the sections 3.1 - 3.6 but mostly look at closing up your model and search for "recalculate" to fix inverted faces (aka backwards normals). If you think your model meets manifold and normals required for Cura then please post your STL.

Are you talking about a ufp file? I don't think it's possible to add a thumbnail to a gcode file.