Fighting with computers

Computers are not always friendly.

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.

Wednesday, November 08, 2017

AMD proprietary driver experience

A while ago I bought a new 4k display and my old graphics card could not handle it anymore so I bought a new card, AMD RX 460 with DisplayPort and HDMI outputs that would be ok for the new screen resolution. I bought that card that apparently had decent Linux support.

I did not notice then that in order to get it working I would need to move from 14.04 to 16.04 Ubuntu LTS, but I did the upgrade and it worked but with a software render mode that was quite slow.

Some more googling and I installed the proprietary amdgpu-pro driver, that worked but not ok, among other problems I got:

  1. Numbers on Google spreadsheets won't show when using Chrome (but did with Firefox)
  2. Openscad would crash when rendering a design
  3. Processing programs, any of the examples that uses P3D (OpenGL) would crash.
  4. When my kernel was upgraded from 4.4 I got a failed graphics driver, when trying to upgrade it did not work till I install HWE. And even then I needed to set nomodeset in grub
  5. I experienced random lock-ups, windows noise background and ocassional flicker, mostly when resizing. 
I reported them to AMD and while the second one was fixed with amdgpu-pro 17.30 the othres kept on happening after several upgrades. 

I ran away from Windows long time ago to get a better user experience and this driver brings back bad memories from the past. Definitely not the typical pleasant Linux experience of the last ten years.

So browsing away I learned about the Linux kernel driver support for my card and I removed the driver from AMD

amdgpu-pro-uninstall 

and installed the "open" one:


sudo apt-add-repository ppa:paulo-miguel-dias/mesa
sudo apt update
sudo apt install xserver-xorg-video-amdgpu

Now I am back in business without any of the problems I mentioned above associated with the proprietary driver. I am not sure if all the pain could have been prevented if I never attempted to use the proprietary driver in the first place. I will definitely remember that for future system upgrades.

Update Nov 28th, 2017

After today's system upgrade my graphics are broken again (software render is as slow as to cause real pain). Starting up a 4.4 kernel, at least keeps the graphics acceleration running but I am experiencing a level of disgust that is dangerous for the health of my graphics card.

Oops, why is my /etc/default/grub having a nomodeset in the kernel loading parameters? Getting rid of it get everything working once again.

Saturday, October 14, 2017

Getting work done faster on a CNC machine

I have been playing with CNC machines for a while and one idea of improving their performance
came to my mind: what if, like they do with processors, we could add some parallelism to the process to get more work done in the same amount of time? So a multi-core processor will be the analog of a CNC machine with several spindles.

As usual, a quick look at the Internet reveals that a "dual-gantry CNC" is not really a new idea as a few videos can be shown on youtube from some commercial units. Interestingly enough, there are just a few cases shown, which makes me think it is either a bad idea or too complex to work properly in most cases.

My plan here is to have two gantries that move independently and to follow the RISC approach: I will handle the dependencies in software so I will create to g-code files, each one feeding one of the gantries in a way that both gantries planing contains no collisions. I guess another approach could be to put in place some kind of collision detection system that would pause one gantry when a collision was about to happen, but that seems less efficient than creating a manufacturing plan containing no pauses (or collisions :-).


This first video shows how a sample job would be split into two different parts. If the motion is done in both cases left to right, there seems no gantry collision would happen. However, this raises the point of where to perform the cut. Just in the middle does not guarantee each gantry would have to work the same amount of time, and if that does not happen, then one gantry is going to finish sooner than the other, leading to unbalance workload and reduced overall efficiency.  

So a good workload balance needs to be obtained by dividing the sheet into two parts with similar workload (which usually would mean one side is wider than the other) as the next video illustrates.


However, though the left-to-right scanning pattern seems very appealing in terms of guaranteeing a collision-free motion for the gantries, it is quite difficult to obtain the best performance out of this pattern so a compromise will have to be done. Like the one shown in the next video, where motion evolves from left to right but some leeway is allowed so gantry can move right to left within certain limitations so the overall toolpath remains shorter than the one with a unidirectional motion yet still remains collision-free.

Please note that last video is not performing a real-time simulation of the approach, so do not be surprised if one half of the work finishes sooner than the other. The actual simulation shows that both halves would require exactly the same running time and therefore would finish at once.

If you've worked with similar systems do not hesitate to pitch in with your comment. If you haven't but want to share your ideas, you are welcome too.



Sunday, October 01, 2017

Random rant of the day

A couple of details made me waste some time till I figured them out. First one was an issue with povray 3.7 running on Linux that would preview a black background when I wanted a transparent background. Output was a PNG file and the final result was ok, but I failed to notice that there was an error with the command temporary output to the display and not with the final rendered file. I noticed the problem once I ran the same command with the same files on my Mac and preview shown the checkered pattern of a transparent background.

used with permission

But this does not mean the Mac versions are any better: Second problem, using Meshab 2016.12 version it was impossible to get a snapshot with a transparent background either. It appears it is a known issue too.  Same version of Meshlab but running in Ubuntu worked like a charm.

I had a third problem I can only blame myself for: it turns out STL files and Povray use a different coordinate space, so my renders appeared flipped horizontally. Nothing that ImageMagick cannot fix (convert -flop).  And yes, y-axis is up on povray, so instead of figuring out how to fix that there I just rotated the rendered bitmap so it looks z-axis is up instead.