Fighting with computers

Computers are not always friendly.

Saturday, February 03, 2018

I bought a Prusa MK3 too

 first layer adjustment). I have been testing each new version of Josef Prusa printers and I am glad at how good and predictable the build process is turning, and documentation is getting better at each new release.

Prusa i3 MK3 is addressing quite a few shortcomings of these type of printers with a good dose of innovation and ingenuity.

I ordered my printers in October 2017 and got it here last Monday. I knew there was a significant waiting time but I was not in a hurry at the time. And it seems to wait has played in my favor as I have received some improvements over the original release (mine are definitely hardened rods). But I  will yet have to wait for a PEI laminated steel sheet.

This time I built the printer by myself: it is more entertained when you have a helper that can double-check the manual, but version 3.0 of the manual is already very good. My only complaint on that front is that although it is clear Prusa Research is doing an effort with a full-color manual in a large format, the pictures are sometimes not contrasted enough. Fortunately, that can easily be solved as the original pictures are very good and available in the online version of the manual at manual.prusa3d.com so those with poorer sight like me can get a better/larger view of what was not clear enough in the printed manual (I really needed to check the online manual just a couple of times only during the wiring phase).

I was expecting to build the MK3 faster than the MK2S. I built one MK2S a few weeks ago and it took me a morning with my friend helping me out. I expected the new Y-axis of the MK3 would be much faster and it probably is, but I build it the wrong way first. As I was trying to go fast, I jumped quickly to conclusions that turned out to be wrong, not a manual's fault but user error.

But eventually, I managed to build it right. It took me around four and a half hours of built time, plus almost another hour of wizard (self test + xyz calibration + It feels much sturdier than before and Y-axis motor no longer will wobble under belt tension (as it could do with MK1 and MK2 till they added one plastic part on the MK2S).

I have zero problems with missing hardware or plastic parts, all the bags seemed to have just the right amount of components though I managed to somehow skip step 35, which I corrected after the self-calibration was over.

Once the built was over, I tested PowerPanic feature and it recovered a part when I plugged off the mains plug mid-print. It detected and recovered from missing steps on X-axis when I intentionally blocked X carriage, but I failed to obtain the same result at the first attempt on the Y-axis, but it worked at my third attempt. It seems a bit particular, but time will tell me whether this feature is good enough.

Filament detection failed miserably, so my test 3Dbenchy had to be scrapped. Later I found out the filament detection feature was disabled by default now.

No sign of noise on my power supply makes me think they have found how to solve that issue too (though I might just have not so sharp an ear as other makers).

I bought this printer because I thought it packed a significant number of improvements and I am glad I did. I am very happy with the reliability I have got from the MK2 and MK2S printers I use, which literally have been printing non-stop for several weeks in a row. So I hope this new one will match or improve the former ones, time will tell.

Monday, January 29, 2018

More SAMD21 M0 weirdness

My assumption was that using Arduino IDE was the quickest and simplest way to venture into the world of 32 bit ARM processors, but I am starting to think otherwise. This post is the second about things not working as expected and time used to figure out what's wrong.

For a motor-controller project, I was testing Allegro's A4950 h-bridge when I realized that while varying motor speed using a PWM signal, sudden torque spikes were happening.

My first idea was that the power supply was to blame, so I replaced it, to obtain exactly the same result.

The code I was running was very simple and on close inspection, I could not find any reason for the observed glitch, that somehow had a periodic nature: one acceleration and deceleration period would work ok and the next one will show three or four torque spikes.

As I was using an Arduino-form M0 board (SAMD21-based) I decided to bring back my trusted Arduino UNO and to run exactly the same code. This time all worked nicely, no sudden accelerations on the motor while speed was going up and down.

So next stop was to grab the M0 PWM output and to look for possible anomalies that would explain the problem (or maybe the problem is with the h-bridge I am testing, after all, I have never used that chip before).

So this is a quick recap of the captured PWM signal:

This is the PWM cycle before the glitch where duty cycle was 75.75%

Suddenly the next cycle is ON 2.3ms while the former was only 1.034 milliseconds, to account for a duty cycle of 87%. That was totally undesired and unexpected.

And the next PWM cycle after the glitch goes back to normal, again 1.028 milliseconds of ON time to account for a duty cycle of 75.17%.

So there it was, it appears that some of the calls to analogWrite may cause some glitch in the PWM output. If I want to keep on using this board I will need to figure out how to change the PWM duty cycle without experiencing that problem, which means to use some time to learn how SAMD21 timer registers work.

That is why I am starting to think that I rather use 8-bit Arduinos for prototyping as they have quite a predictable behavior while the same seems not to be true for some of the new brethren. While this may look like some Arduino-bashing article it is not. It is more a warning call for people like me that want to save themselves the pain of ARM datasheet reading.

Tuesday, January 23, 2018

Guess who is coming home?

Have you ever wanted to know if someone is coming home even before they ring the bell? I do not have a dog (they have that kind of power too) so I have to look for a solution on another domain.

So last weekend I decided to see if I could use an ESP8266 for that purpose, given that my sample subjects, aka sons, are equipped with smartphones with a MAC address I am aware of.

But the point is that if I wait till I can detect their phones are joining the home wireless network, they are probably at the door already. I am looking for something else that can pick them up sooner, even if their phones cannot yet pick up the home network wifi signal.

Googling around I found this code. It is a basic sniffer of wifi control frames. In particular, it is looking for probe frames that wireless stations can emit from time to time to discover nearby wireless networks.

But be warned that while the trick seems to work fine for Android phones, it does not seem to work for iPhones as they use to use a random MAC for probe frames.

As my results, well, it just works. I guess your mileage may vary depending on many factors. I get a one-minute warning, most likely their signal is detected when they enter the building.

An alternative (or complementary) use could be an early warning for the postman, the UPS guy, etc. But for that purpose, you'll need to figure out their MAC addresses, which is not difficult as the ESP2866 code gives you the signal level (RSSI) of the probes received, so a new MAC with a power signal when you have a visitor is going to be noticed.

Tuesday, January 09, 2018

Wemos M0 PWM weirdness

One of the things I have received as Xmas gift is thus Arduino UNO form factor board with a Cortex-M0 processor running at 48 Mhz.

After getting some trouble with the Arduino IDE I managed to get it working as an Arduino M0 in 1.8.5 IDE. However, though I could upload code, analogWrite seem not so work for me.

I used Fade example code that should work with built-in LED on pin 13 but it did not.

I had to use my logic analyzer to check which pins work with PWM and which do not. I could see that Adafruit using a similar processor mentioned some trouble with some pins but my board was even worse than that. Only pins 12, 11, 10, 9, 8, 5, 4, 3, & 2 worked with PWM while others, like pin 13 should work but did not.


At least now I know which pins I can use for analogWrite. I am not sure what the root cause of the problem is though.

Thursday, December 28, 2017

Building a Prusa i3 MK2S

A friend needed a 3D printer for a project and I recommended him an MK2S as he was in a hurry. Printer took three days to get here and after the holidays we had to build it yesterday, but the flu forced me to delay that.



The good thing about doing yet another build is that I am quite familiar with the design and the kit, and the problem is that I am quite familiar with the design and the kit too. The latter makes you skip steps and/or fast forward into the build so you have to stop, go back to where I messed up, follow the instructions to the letter and get back on track.

Even funnier [so to speak] is when you know something is important no to skip (like which side should be up on the Y-carriage) and still missing the point: I knew it was important to make sure to identify the side with the mark. The picture showed the mark upward. Next picture detailed where the first linear bearing should be placed on, so just went on with the instructions, assuming the mark should be up while doing the assembly. Once it became obvious I have missed the point many steps forwards, I went back to realize the second picture had some text stating the mark should be facing the table while placing the bearings on top of the Y-carriage part :-(

All in all, I made just a few of these silly mistakes but the printer was built and up and running over the morning. A small test vase was half-printed during the afternoon and a fifty-hour long part is now being printed after all seemed ok.

I have found the MK2S build much improved in terms of cable handling and RAMBo-cover. Extruder part requires you keep your alert as there many details you need to do right (many different screw sizes and captured nuts). I guess instructions have been improved too. The new way of supporting the linear bearings to the Y-carriage is great but tightening the lock-nuts with the needle-nose pliers is a bit of a pain, unfortunately, I had to use just that.

Recollecting the mistakes I made along the build:

  1. I press-fit the smooth rods too early on Y-axis
  2. Placing Y-carriage upside down
  3. Tightening Y-motor before passing Y-axis end-stop cable first
  4. Tightening X-axis pulley the right distance to the motor but upside down
  5. Starting to place the extruder tensioning screws before placing the idler first
  6. Not noticing the colored measurements for the front and rear plastic parts of Y-axis
I made an operator's error while XYZ calibration was taking place: I attempted to place the spool holder parts on the top of the frame. These new holder parts are injection molded and too tight, so there was no I way I could fit them, and while I tried I caused an error on the calibration process than once repeated ended up uneventful. So the moral here is twofold: on one hand, let the calibration do its magic with being disturbed and on the other hand, use a cutter or x-acto knife to trim a bit of the spool-holder part so I will fit snug over the frame.

Kit printed parts quality was quite good but I have got one crack on one of the Y-axis corners when pressing the smooth rod the first time. Other than that nothing broke and nothing was missing, but one picture showed the nut of the PINDA probe while that nut was missing. However, the text warned that if present it was to be removed. I had to use a couple of extra M3x30 screws for joining the PSU to the Y-axis frame (a change of size was mentioned in the manual).

I just can't wait for an MK3 kit that is coming my way in a few days. I hope it will work better than the sample printer delivered to Thomas Sanladerer

Tuesday, December 19, 2017

H-bridge and PWM for DC motor control

Several times when controlling a DC motor with PWM over an H-bridge I asked myself what could be better during the OFF part of the PWM cycle. I reckon three basic choices are possible:

  1. If all the switches are OFF, then the back EMF will flow through the flyback diodes of the bridge.
  2. The same action as above could be achieved if the switches opposite to the PWM-ON cycle where ON during the OFF period. A braking action is caused.
  3. The motor could be shorted by closing the top (S1+S3) or bottom switches (S2+S4) thus shorting motor current and again creating a braking action too.
Options 2 and 3 correspond to the fast and slow decay modes when the H-bridge is used for controlling one coil of a stepper motor. And even there, it is possible to mix and match so both can be used during a percentage of the PWM OFF time. 

But my doubt came from a user of my dcservo project, who alerted me that a motor was burned and he thought it was caused because my code was using option 3 during the PWM OFF time. That got me thinking whether he was right or not.

In different moments I have used interchangeably options 1 and 3, that is to allow the motor to coast or to brake it when the bridge was not energizing the motor. Mostly due to the availability of pins on the microcontroller or the features of the H-bridge used (some may not have a enable pin). 

A bit of searching led to these great articles on H-bridges, where basic operation and the details of Sign/Magnitude drive and Locked Anti-Phase drive were discussed. Each of them using option 2 or 3 but not 1 made me think that my approach was certainly not wrong.

However, it is possible to just let the motor coast during the PWM OFF time if the bridge has an enable pin. The net effect is that this type of drive will reduce power dissipation on the switches (as they will be on less often) and the motor could run freely when disabled. That may be a problem for a speed control of a robot if the speed command is zero and the robot is downhill, as it may roll all the way down. For a position control, this seems less of a problem, but having the drive both positive and negative torque seems like a better deal for a precise control. 

So my next step is to check whether Lock AntiPhase drive can give me better positioning accuracy over Sign/Magnitude or not.

Wednesday, December 06, 2017

Helping video projectors to behave

My friend, artist, and colleague was planning an Arts exhibit and asked me a simple question: How can I best [automatically] switch off some video projectors I am using?

After some experience, I have come to realize that Interactive Art projects have the additional complexity of day-to-day starting and stopping. Most places have staff who can take care of operating an electric switch or a remote control, but anything more complex than that and you are in trouble and the success of your project may be jeopardized by improper setup. So it is the best interest of the artist to streamline the process as much as possible.

It is really not a problem to ask the staff to switch on an Arts installation using a remote control but, if you want your piece to shut down by itself you may need some convincing. What is really a bad idea, and unfortunately I am witnessing this with all kinds of equipment on campus, is to just remove power from the device you want to switch off. The reason is that many devices, from computers to video projectors to AC units require a specific shutdown sequence to make sure no damage is done.

Most video projectors will warn you against shutting them down by removing power. If you chose to ignore the warning you may quickly get in trouble (short light bubble lifespan and these are expensive). So what do you do for shutting them down automatically? My proposal is to transmit the same infrared signal the remote sends for powering it on and off using an Arduino. You can program the Arduino so it can power the video projector on and off when you see fit, making the human intervention unnecessary once installed.

But if you want an Arduino to transmit the "power on/off" code,  the first thing you need is to figure out what is the code the remote is sending. To do that an IR receiver is needed. The one I used is the TSOP4838, that works well with 38Khz IR remotes.


I have used IRLib2 with that TSOP4838 receiver, just plugged in on an Arduino UNO board and it worked flawlessly as the picture above shows (I just used the dump example that came with the library using pin 2 as data input). Like many other remotes, mine uses NEC format and the power button spits out code 0x8C73817E. Half of the work is done now.

Once you know the code you want to send, you can use the same library for sending purposes. By default digital pin 3 will be used for output. Depending on the distance you want to cover you can get away with powering the IR LED from the Arduino pin or not. Most of the time you want to cover a decent range and to achieve that you will use a transistor to boost the current on your LED to 50 or 100mA (depending on the specs of your LED). Some people do not even use a current limiting resistor in series with the IR LED as they claim the current pulses are so short and infrequent that the LED will not be damaged and emitted power is peaked this way. I just used a BD137 bipolar transistor and 100-ohm resistor in series with my IR LED.  Have a look at the rawSend example from the library to learn how to transmit an IR code.

Most of our video projection units require pressing the power button twice to power them down. After some experimentation, I settled on a 3-second pause in between the two transmissions (as longer or shorter pauses would make my attempt not to power down the projector). 

A detailed explanation of IR communications with Arduino can be found on this excellent video by Andreas Spiess.