Fighting with computers

Computers are not always friendly.

Tuesday, November 25, 2014

Loading TinyG2 in the Arduino DUE

I have been intrigued for a while with TinyG controller and their S-shaped speed
curves. It is an
evolution from simpler trapezoidal speed patterns used by GRBL software and by most 3D printer firmwares out there too.

However, TinyG (besides a South Korean music group) is not designed to work on a regular Arduino but over more powerful Atmel processors, the XMega series. While the software is open source, it does not help if you do not have the right processor. But lately I am giving a course where I have borrowed an Arduino DUE, which happens to be supported by TinyG project too.

Uploading the code has been a bit of challenge, partly due to my attempt of using a USB cable with broken data wires (I did not know that as I use it for charging my cellphone). But even with a good cable, the upload process, at least using OSX was a bit of a challenge. It all comes down to a not entirely cooked script from their github.

As I am not familiar with ARM development conventions, I see there is a binary file that I can download, but it is a .elf file. Apparently, the uploader program, bossac, cannot handle the .elf file for reasons I do not understand. It needs a binary file instead, and that can be obtained with an obscure command (at least for me): arm-none-eabi-objcopy -O binary tinyg.elf  tinyg.bin

Once I have got the binary file, I can upload the code happily with command bossac  -e -w -v -b tinyg.bin -R

However, the built-in script from the git, DueFromOSX.sh failed miserably on my computer.

As usual, my downloading of Arduino IDE that was required, 1.5.8 version, was not successful at first as the Java 7 version is apparently not the one that I have installed but Java 6. Nothing that could not be fixed downloading the right one. But I was surprised how tricky the process has been as a whole.

Unfortunately I have run out of time for testing the DUE with grbl shield on my ShapeOko to see if there is a big difference from its older brother GRBL. Maybe another future post.

Update

For Linux, I did not have much luck with the direct usage of bossac command, however I was puzzled at how Arduino IDE will work flawlessly in Linux while still it was using bossac. So I realized the culprit was the need of a previous setting the port to 1200 bps to reset the board and clear the memory, this is the command that worked for me to upload code to the Arduino DUE from Linux command line:
stty -F /dev/ttyACM0 1200; sleep 1;  bossac --port=ttyACM0 -U false -e -w -v -b TinyG2.bin -R

Thursday, November 13, 2014

Another one bitten by the bug

While I have been doing electronics since I was a kid I never owned an oscilloscope before. At a local meeting of Arduino users a colleague mentioned me there was a very good offer of a four channel sampling oscilloscope. Not that I need to use it very often but I was curious enough to see how instruments have evolved lately I decided it was about time to have my own scope so it was kind of a birthday gift I bought to myself (if that makes any sense).

First thing I have measured, just because it's right next to me is the the ringing of my 3D printer's hotend PID regulator output. It has been mentioned voltages can get pretty high over there in RAMPS boards and boy, that is true. At around a 50-volt spike is produced when the load is switched off. And the real value can only be appreciated if you freeze the sampled signal and expand widely the time axis, as the spike duration is below 1us. I guess total energy is so small the MOSFET is not really damaged (as it has been sitting there for three years now without stop working). Values in the order of micro Joules seems to be safe as the STB55NF06L is avalanche tested and the single pulse avalanche energy is 300mJ.

This second image shows the moment the heated bed of my printer is switched off. It shows how the highest peak is actually triggering the avalanche mode in the MOSFET (avalanche voltage is rated 60V).