Fighting with computers

Computers are not always friendly.

Friday, July 29, 2016

Buliding a Prusa i3 MK2

I have built (or help others building) quite a few Prusa i3, from sets I sourced myself, including the self-printed parts to commercial kits from bq or Josef Prusa himself. But when I saw the latest i3 version I was surprised about the ingenuity of some its solutions.

Having used kits from Prusa3D before I knew they left no details unattended, so I could understand them charging more than others. We are very happy with the i3 we built from kit so next time we needed to get some printers I had to decide between what I reckon are two good choices: bq's Hephestos 2 or Prusa i3 MK2. H2 has larger bed but it does not have a heated bed. MK2 can do more materials and can print hotter than H2, so we stayed to that.

The kit comes is a box similar to the cardboard box of a mini-tower PC. There are different smaller boxes and plastic bags inside with the assorted components.

 And it comes with its own set of tools (not the red box but the other tools).
 Motors come well protected, as some of them now have a long threaded shaft, plus each motor is identified with the axis name.
 Plus a bag with all the printed parts, any color you want as far as it is orange (there are a few black parts too).
 The power supply comes pre-wired and protected by a plastic part that holds a power switch and a power socket.
 Now let's begin the build. Kit comes with a full-color manual with  pictures and explanations, but you might want to have a computer nearby so you can zoom-in whenever you need a better picture (my sight could be better). Steps are numbered and there is a bag of metal parts and a bag of plastic parts for each step. Just follow the manual and you will be ok.
 Little by little some differences start to appear. And you may even panic. Like when it seems there is something wrong with the new y-axis belt holder, whose screws apparently go through an untapped hole in the y-carriage x-shaped part. And it is then when Prusa3D plays what I think is one of their better assets, they have a chat applet in their website you can use you to get support in real-time. So in case of doubt you can contact them to help you realize there was nothing wrong and that you just missed some detail because MK2 does some things a bit different (there are no tapped holes anymore on y-carriage in case you are wondering).
 Another thing that is differnt is that now z-axis motors come with a built-in threaded shaft.
 X-axis does business as usual but now it includes room for an end-switch and later you will need to add the somehow tricky z-axis nuts.
 Just follow the suggested sequence and your machine will be taking shape.
 Did not I mention candy is part of the kit? What is unclear is what is the best step to use it, as the manual does not mention it nor the bag has a number attached. Anyway, it is a nice touch too, that might even please any little ones you might have around.
 So after three hours of work we were like this.
And one hour later our built was finished. Our biggest mistake was to mount y-carriage the wrong way, so later we could not fix the heated bed to it. One shameful chat later, we realize what we did wrong and fixed it and the build was done.

However, it took us one hour more for setting up the machine. Making sure all was square was easy. Do not forget what the kit does not include but you will need is a ruler, at least 100mm long. Another thing that can be useful to have around is a wire cutter for trimming the many zip-ties you will use. We used the pliers from the kit but those will leave a long-ish piece of material.

Our first print was a PLA batman that failed almost at the end as the model included no heating of the bed, I do not know why.

All in all, I am impressed with the kit.

Friday, July 22, 2016

Useful uses of screen command

Every now and then I am using command-line tools. I work with daily with OSX and Linux and they both have in common the availability of a powerful command line tool.

The same could be said about Windows, but that would be an overstatement, as CMD.EXE provides not the efficiency level that can be achieved with other systems. But even if it could, they chose to make it different.

Anyway, many times I am working over remote terminals on other's computers command line tools and one thing that may not be welcome is for a program to destroyed your temporary data or to just stop working whenever the connection is broken.

If you are using a so-called broadband router you may realize than some remote terminal sessions die for no good reason. (The real reason is that after a few minutes without seeing any traffic through a TCP connection your home router will kill the connection without you knowing it). Let say you are editing a text file on a remote computer through an ssh connection when you get a telephone call that keeps you a few minutes away from the computer and, when you are back, your terminal session dies with an error message. It might mean the changes you did to that file are lost forever. That would be a bad thing.

There is one command that can help here, keeping the text editor program and your session frozen but alive while your ssh connection is destroyed summarily by your broadband router. The screen command allows you to create a terminal that does not go away when the connection is broken. A terminal session you can safely return to later.

Other usage case that I face from time to time is that I want to launch a program, maybe a long simulation, on a remote computer. If I do not keep the terminal open all the time, the program running on the remote server will be killed by the system. But even if I decide to keep my computer connected, still the connection may be killed by (you are guessing ...) your home router. And the worst thing is the next morning you will not have the results of the simulation and you will need to start from scratch.

Once again, you can connect to the server and start a screen session before starting the simulation, this way you can cancel the remote terminal session at any time with the confidence that your simulation will keep on running till the end. Next morning you can connect again to see the results and, if desired, finish that screen program.

Even better is that screen command is not limited by one terminal per user but you can have as many as you need. And switching from one to the next is as simple as pressing Ctrl+A and next pressing N.

 Yet another scenario is when you launch a program on your office computer (let's say you love simulations and it is just another one). Now that you are home you would like to check the intermediate data the program is printing to the screen but you cannot do that (unless you have some remote desktop software running on your computer).  However, if you started a screen session before launching your program, then that session can be detached from the original terminal and attached the new with the screen -D -r command.

It is a really interesting tool with only on drawback: that you will loose your terminal's scroll mechanish. So now, when you attach to a certain screen instance, you can see the content of the current screen but you cannot scroll back to see the lines that were printed before. Other than that, it is pretty useful.