Author Archives: teel9174

CNC Machine

I have had a MyDIYCNC Machine sitting around for a few years now. I was having some problems with the controller boards so I set it aside and am just getting back to take another look at it. I found that one of the boards that was sent to me was indeed bad but MyDIYCNC no longer sells machines or parts. I then decided to go to Amazon and pick out a controller board to try. I picked the SainSmart CNC TB6560 3 Axis Stepper Motor Driver Controller Board & Cable. This board seems to work quite well. I have been having a bit of a time getting it to work properly in LinuxCNC but I have got it to home and move but it seems to be at 1/2 scale. I am still tweaking with the settings to see if I can get it to work 100%.

A few notes about wiring and hardware. The MyDIYCNC instructions refer to the motor which moves the Z axis carrier as the Y axis. It appears that it should really be the X axis and the table should be the Y axis. If it were the Y axis, the home position would be in the wrong corner of the machine. I played with the configuration a bit to see if I could get it to work as expected but I had no luck. Finally when I decided to try to swap the X and Y axes did home line up in the correct corner. I could have swapped A & B around on the Y motor and that may have reversed the direction of the motor but I did not want to go there. Swapping the axes made the most sense.

Here is a short video of a test of the CNC. The spindle has a ink cartage in it and is simply running the default LinuxCNC project. The drawing should be 5.3 inches wide but is only half that size.

Here are the settings for LinuxCNC.

Base Information

  • Machine Name: MyDIYCNC_inches
  • Axis configuration: XYZ
  • Reset Default machine units: Inch
  • Driver type: Other
  • Driver Timing Settings (The Stepper Drive Timing page on states that 150,000 ns should be used for all values however the current version of LinuxCNC has a max value of 100,000.)
    • Step Time: 100000
    • Step Space: 100000
    • Direction Hold: 100000
    • Direction Setup: 100000
  • Base Period Maximum Jitter: 9000

Parallel Port 1

  • Outputs (PC to Mill):
    • Pin 1: Amplifier Enable (Invert)
    • Pin 2: X Step
    • Pin 3: X Direction
    • Pin 4: Y Step
    • Pin 5: Y Direction
    • Pin 6: Z Step
    • Pin 7: Z Direction
    • Pin 8: Unused
    • Pin 9: Unused
    • Pin 14: Spindle ON (Invert)
    • Pin 16: Unused
    • Pin 17: Unused
  • Inputs (Mill to PC):
    • Pin 10: Both Limit + Home X (Invert)
    • Pin 11: Both Limit + Home Y (Invert)
    • Pin 12: Both Limit + Home Z (Invert)
    • Pin 13: ESTOP In
    • Pin 15: Unused
  • Parport Base Address: 0
  • Output pinout presets: Sherline (The value here is not important. It is actually used with the “Preset” button to load values.)


Selections here really do not matter. I have not figured out how to use these yet. I may look into it more in the future.

Axis X

  • Motor steps per revolution: 800 (Steppers included with MyDIYCNC are 50 steps per revolution. The TB6560 board has the switches set for 1/16 microstepping. 50 x 16 = 800)
  • Driver Microstepping: 2.0 (Someone posted that 2 meant that microsteping was being used. I had this set to 32 earlier.)
  • Pulley teeth (Motor:Leadscrew): 1.0:1.0 (All axes are direct drive so they are all 1:1.)
  • Leadscrew Pitch: 20.0
  • Maximum Velocity: 0.4
  • Maximum Acceleration: 30.0
  • Home location: 0.125 This took awhile to get. If using the limit switches as home switches as well, we need to back the machine off so that the limit switches are not active when at home position. I choose to back them off 1/8 inch on all axes.)
  • Table travel: 0.0 to 5.5
  • Home Switch Location: 0.0
  • Home Search velocity: -0.05
  • Home Latch direction: Same

Axis Y

  • Motor steps per revolution: 800
  • Driver Microstepping: 2.0
  • Pulley teeth (Motor:Leadscrew): 1.0:1.0
  • Leadscrew Pitch: 20.0
  • Maximum Velocity: 0.4
  • Maximum Acceleration: 30.0
  • Home location: 0.125
  • Table travel: 0.0 to 8.0
  • Home Switch Location: 0.0
  • Home Search velocity: -0.05
  • Home Latch direction: Same

Axis Z

  • Motor steps per revolution: 800
  • Driver Microstepping: 2.0
  • Pulley teeth (Motor:Leadscrew): 1.0:1.0
  • Leadscrew Pitch: 20.0
  • Maximum Velocity: 0.4
  • Maximum Acceleration: 30.0
  • Home location: -0.125
  • Table travel: -4.0 to 0.0
  • Home Switch Location: 0.0
  • Home Search velocity: 0.05
  • Home Latch direction: Same

Almost Done

Do you want to quit?

Screenshot added for completeness

I plan to continue to look into what is going on with the scaling and settle on the correct settings or at least settings which will work.

Test Video

I would like to add more videos to the blog. One of the problems that I have had is the time it takes to perform post processing on videos to add different sources and information. I found the Open Broadcaster Software application and started messing around with it and found that it is quite good, once you get use to how it works. Here is my first attempt at creating a video with the software.

BTW: Yes, I totally ripped off some ideas from Adafruit. I’m not too creative so I copied what I like. I will attempt to change it but it is tough as Limor and Phil have created a very nice format for the shows that Adafruit produces. I also like Ben Heck and Dave Jones (EEVBlog) videos as well but I seem to watch more of the videos Adafruit puts out.

Here is my first recording.

I2C Communications between Raspberry Pi and Arduino – Update

Over the past few days, I have been able to bit bang the I2C bus with the PIGPIO library. I found a very helpful example at which was posted by crj11. This example was using the pigpiod_if.h library. This worked well but required the application to be run with elevated privileges (sudo) which was not acceptable as I needed to run the application from a Python script which in turn was running every 5 minutes from a cron job. The final solution was to use the pigpiod_if2.h and run the pigpio daemon on startup.

The final solution has been running for a few days with three sensors connected over a total of 9 feet (~3 meters) of cable. The data has been logged at Adafruit.IO which I have made public. I may remove or rename the Dashboard in the near future so here is a screenshot of the page.

I have also updated the GitHub site for the project so there are now two releases available. Version RC_0.0.1 is the version using the hardware for I2C control and version RC_0.1.0 is the bit bang version.

I still have more work to do to make this project valuable to others. I plan to create some better documentation on the project and provide a full write-up to allow someone to follow along and build there own from start to finish. Right now, 80% to 90% is captured in various places but there are obvious gaps such as the connection to the Raspberry Pi. One can figure this missing information out by looking through the right source files and piece it together however I do not like it when I find a project write-up that is only 80% to 90% documented. It is still better than nothing or only 10% to 25% though.

I hope someone will find some of the information here useful.

Sensor with one cable connected

I2C Communications between Raspberry Pi and Arduino – Update, BOM, and Source Control


I have been working on this project over the past couple of weeks when I have free time but have not been posting updates. This is a general update which is why the title is different from the other posts regarding this project.

My boards from OSH Park arrived last week. I was able to populate them and test them out. Fortunately I did not make any errors on the PCB or schematic so they all worked as designed. There are a few things that I would change on a future version if I choose to make another version of the board.

  1. I would put the ICSP header on the bottom of the board so it does not stick out from the front. This would make it much easier to assemble and would make it possible to not have any exposed circuitry which may allow the device to be damaged from static electricity.
  2. I would move the resistors toward the bottom of the board if possible. It would allow the DHT11 sensor to stick out further from the case.
  3. I would also try to push the ATtiny85 a little further towards the bottom for the same reason as the resistors.

Currently I am looking to bit bang the I2C bus on the Raspberry Pi. I seem to have gotten around the clock stretching issue if there is only one device connected to the I2C bus but as soon as I add another device, the clock stretching becomes an issue again. I really wish that the Pi Foundation would work with Broadcom and fix the issue with the I2C bus.

Here are some pictures.

This slideshow requires JavaScript.

Bill of Materials (BOM)

Materials List (For One Sensor)

  • QTY 1 – PCB (Source: OSH Park)
  • QTY 2 – 3.5mm 4 Pole Audio Jack, J1 & J2 (Source: MCM Electronics NOTE: I ordered 27-9485 but received ones which look like 27-9487)
  • QTY 1 – 2×3 Position Male Header 2.54mm Pitch, JP1 (Source: MCM Electronics NOTE: This is a 2×13 header. You will need to cut it for 2×3 header.)
  • QTY 1 – T-1 3mm LED, LED1 (Source: MCM Electronics NOTE: May choose another color)
  • QTY 1 – CDS Photoresistor Photoelectric 5549 GL5549, PH1 (Source: Ebay)
  • QTY 2 – Resistor 1/4W 10K Ohm, R1 & R2 (Source: MCM Electronics)
  • QTY 1 – Resistor 1/4W 220 Ohm, R3 (Source: MCM Electronics)
  • QTY 1 – DHT11 Digital Temperature & Humidity Sensor Moudle, SE1 (Source: Ebay)
  • QTY 1 – ATMEL ATtiny85, U1 (Source: Newark)

Materials List for Raspberry Pi Hat

  • Qty 1 – Perfboard (Source: Adafruit)
  • Qty 1 – GPIO Header for Raspberry Pi NOTE: The one you will need depends on which model of Raspberry Pi you are using. (Source: Adafruit 2×13 Header for original Raspberry Pi or 2×20 Header for newer Raspberry Pi)
  • QTY 1 – 3.5mm 4 Pole Audio Jack (Source: MCM Electronics NOTE: I ordered 27-9485 but received ones which look like 27-9487)
  • Optional items

Source Control

I have added the source files for the Hardware and Software onto GitHub. I did this so the community may have access to the files and any updates to them. I mainly did it because I was having a hard time remembering which set of files I last worked with especially if a few days went by when I could not work on the project. I think this is a win-win for me and anyone interested in this project.

The files are located at When you first go to the page, it may look like there are mo project files included in the project. If that is the case it is because I am still trying to get everything working properly before I commit code to the master branch. You will see a button with the text “Branch: master” and a downward arrow. Click that button and select another branch such as “dev”. You will then see the project files in their current state.

If you wish to contribute, add a comment here or if you can request through GitHub, do that. I will reply once I see the request but keep in mind that it may be a few days.

I2C Communications between Raspberry Pi and Arduino – Part Four

It has been two weeks since my last post but it has been out of frustration on porting the code over to the ATtiny85. The first thing that I ran into was that the Wire library is not supported on the ATtiny85. I needed to modify my code to work with the TinyWireS library. This did not seem too bad and worked once in a while. It was a bit frustrating as I followed examples and it appeared that I was doing everything correctly but that is typically how it goes when coding.

I finally took a look at the specs for the ATtiny85 and realized that memory may be my issue so I started to pare down the memory requirements. The Arduino IDE was not complaining but I recalled an posting that was published on Adafruit a couple of years ago called Arduino Memories. After rereading the article and looking at a couple of other references, I determined that I needed to tackle the memory is see if it was an issue.

At some point in my debugging, I had noticed that the examples for TinyWireS were utilizing a buffer and pointer method to do fast reads and writes. I had a significant switch statement on the request data handler so I removed that and went with the buffer option. By doing so I reserved a whopping 256 bytes for the buffer. This was a very stupid move which I realized when I took a look at the specs for the the ATtiny85. The ATtiny85 has only 512 bytes of RAM so I was consuming half of it for the buffer which did not leave much room for anything else.

I dropped the buffer size down to 32 bytes which helped a great deal. After reducing the size of the buffer, I could get communications between the ATtiny85 and the Raspberry Pi to work a few times before the communications stopped working. I further refined the code to reduce memory usage and swapped out the Adafruit DHT library for one written by Rob Tillaart for the DHT11 only.


With these modifications, I was able to get the code down to using 113 bytes of RAM and 4,918 bytes (60%) of Flash.

With these changes, the code works quite well but sometimes it appears that the ATtiny85 does not read the correct request from the Raspberry Pi. After some searching it was found that there is a known issue with the Raspberry Pi and clock stretching. It appears that there is a bug which has not been fixed yet if the slave stretches the clock at the right moment and the stretching is too short. The ATtiny85 implements I2C in software so this is going to happen at some point.One of the best articles on this issue is the Raspberry Pi I2C clock-stretching bug.

There are some suggested fixes which I need to read more to understand well enough to use. The most promising fix appears to use Python to perform I2C communication in software. The recommendation is to use the PiGPIO library.

Below is the code that I have thus far on the ATtiny85.

Here is the code on the Raspberry Pi to verify that things are working.

Running the Raspberry Pi program produces the following result.


Next step is to see if I can resolve the clock stretching issue and then connect to to post data. If it is not possible to address the clock stretching issue, it would be possible to identify when it occurs and reset the power to the I2C slave devices. I am trying to avoid that solution but I may need to resort to that solution.

I2C Communications between Raspberry Pi and Arduino – Part Three

Today’s goal is to send a string from the Arduino to the Raspberry Pi. The setup is the same as from day two.

After several attempts and stupid mistakes, I was finally able to get a “Hello World” message from the Arduino to the Raspberry Pi.

Here is the code for the Arduino

Here is the code for the Raspberry Pi

Compile the code
gcc testi2c03.c -o testi2c03

Run the code
./testi2c03 254

We can see that once the string ends, the data on the I2C buss is 255. Let’s tweak the code on the Raspberry Pi to stop once we receive 255.

Compile the code
gcc testi2c03b.c -o testi2c03b

Then run the application
./testi2c03b 254

We can see that the output is now cleaner.

Let’s do even better and print the string as a string instead of a list of characters.

Compile the code
gcc testi2c03c.c -o testi2c03c

Then run the application
./testi2c03c 1 2 3 254 250 251

Yes, I included additional arguments this time. The code was setup to handle this which is really nice. This allows us to teak the code if we like to print out what the values actually are and get some additional information. So let’s create a new application which will do exactly that but will not take in any arguments. I am also going to add a few other things such as detecting if we are using a Raspberry Pi Rev 1 or Rev 2 as well as scanning the I2C Bus.

I was doing some searching on valid I2C addresses and found a great reference article from Total  Phase at 7-bit, 8-bit, and 10-bit I2C Slave Addressing. The article provides a diagram showing the valid range of 7-bit I2C addresses.


From this diagram, we can see that the address used in the examples is a reserved address. I will change the address in the Arduino code so that it is in the valid address range.

Here is a modified version of the code which finds all connected I2C devices. Determines which ones are the sensors that we are interested in, and reads values from each one. This will be a great program for making certain that the design works and all of the sensors are working.

Arduino Code

Raspberry Pi Code


Compiling the Raspberry Pi code is a bit different as we need to link the math library. In order to do this, we need to add -lm to the command line.

gcc testi2c03d.c -o testi2c03d -lm


Here is the results of running the application.


The passing of a string was successful however there are several standards which may be better suited to the goal that I have in mind. One worth further consideration is the System Management Bus (SMBus). For the moment, I am leaving the code as is since the information that I need to send may be sent as simple integer responses. A future enhancement will be to get a better messaging system in place.

The next step is to replace the Arduino with a ATTiny85 and get it all working.

I2C Communications between Raspberry Pi and Arduino – Part Two

The goal of the day is to get the Raspberry Pi and Arduino talking to each other over I2C.

I followed a few examples provided on the internet and was able to get the two to talk to each other. Just to be clear, the Raspberry Pi will be the I2C master and the Arduino will be the slave. One of the nice advantages to this configuration is that it is not necessary to do any voltage level shifting between the two devices. If you are not aware, the Raspberry Pi GPIO is at 3.3V and the Arduino is at 5V. If the Arduino were to supply 5V to any of the Raspberry Pi’s GPIO pins, the Raspberry Pi will be toast.

I followed the tutorial at Below are some of the high level steps.

  1. Download the latest Raspbian image from
  2. Unzip the file and write the image to the SD Card using Win32DiskImager from
  3. Once the Raspberry Pi boots, open a terminal window and run raspi-config to enable I2C Support
    sudo raspiconfig
  4. Select “Advanced Options” from the menu
  5. Select “I2C” from the Advanced Options menu
    Select “Yes”
    Select “OK”
    Select “Yes”
    Select “OK”
    ”Select “Finish”
  6. Install i2c-tools
    sudo apt-get update
    sudo apt-get install i2c-tools
  7. Run i2cdetect to make certain that i2c-tools installed properly
    i2cdetect –y 0
    i2cdetect –y 1
    If all worked well, you will see the following output
    If there are devices connected to the I2C pins, you will see the devices listed as in this example.
  8. Wire up the Arduino and Raspberry Pi
    Raspberry PI        Arduino
    GPIO 0 (SDA)    <–>    Pin 4 (SDA)
    GPIO 1 (SCL)    <–>    Pin 5 (SCL)
    Ground    <–>    Ground
  9. Upload Code to the Arduino
  10. Write the application on the Raspberry Pi
    nano testi2c02.c
  11. Type of copy paste the following code
  12. Save the file by pressing <Ctrl> + o

  13. Exit the editor by pressing <Ctrl> + x
  14. Compile the application
    gcc testi2c02.c -o testi2c02
    If you do see errors, go back and edit the file to correct them.
    Once the changes are made, recompile and if you do not see any error messages, you are good to go.
  15. Run the application
    ./testi2c02 1 {Gets the temperature in Celsius}
    ./testi2c02 2 {Gets the relative humidity in percent}

    ./testi2c02 3 {Gets the light level}

    ./testi2c02 4 {Turns the LED On}

    ./testi2c02 5 {Turns the LED Off}

    ./testi2c02 6 {Flashes the LED when reading sensors. This is the default behavior of the LED}

    ./testi2c02 7 {Echos the number 7. This may be repeated with any other number up to 255}


That’s all for the day. Next I plan to try to send strings and develop a format for messages.

I2C Communications between Raspberry Pi and Arduino – Part One

My daughter has a science project for school on bread mold growth. She will need to monitor the temperature, humidity, and light level of 3 separate environments. Being the geeky dad that I am, I decided to make her some data loggers to monitor each environment. I would also like to take this further by connecting to an online IoT site such as to store and graph the data. There are a few options available such as using an Arduino with a Wi-Fi shield to connect to the site and monitor the environment but that is not an elegant solution. What I have opted to do is to use a Raspberry Pi instead and use I2C to communicate to the sensors using ATTiny85 microcontrollers. One of the reasons for this choice was that she will need to monitor the growth with 10 to 30 slices of bread for each environment. With that many slices in one batch,  there could be a considerable variation throughout the area containing the bread so more than one data logger/sensor cluster should be used. I2C is the perfect solution as you may have up to 127 devices connected with just 3 wires.

Use an Arduino Uno R3 to get information from the sensors and verify that the code works correctly.



Arduino Code




Next Step -> Add Raspberry Pi and I2C Communication

Portable PI – Power Supply and Power Switch

Finally nearing the end of completing the power supply and soft latching power switch. The components have changed slightly but the principle design is the same. The components include two li-ion batteries connected in parallel with protection circuit, soft latching switch, Adafruit Powerboost 1000 with charging circuit (Product #2465) , and a Teensy 3.1. Along with the hardware components, there are two software pieces with one residing on the Teensy and the other running in the background of the Raspberry Pi.

The design utilizes a soft latching power switch has three functions. It powers the device on from an off state, signals the Teensy that the user has pressed the power button to request a shutdown, and power off. One of the main requirements besides those mentioned above is that the soft latching power switch must not draw current or very little current when in the off state. This is necessary as we do not want the batteries to be drained when the device is in the off state.

These requirements were met with a modified version of the soft latching power circuit described in my earlier post. The circuit was modified for a couple of reasons. First of all, the circuit needed to be able to operate from 3 to 4.5 VDC rather than at 5 VDC. Another reason the circuit needed to be modified is that the output was floating when off so the enable signal to the powerboost circuit would cause the power to cycle back on after a few seconds.

There are two pieces of software working together which allows the Raspberry Pi to safely shutdown when the user presses the power button. The Teensy has software which monitors the power button to see if it is pressed and monitors the USB power from the Raspberry Pi. If the user presses the power button, the Teensy changes the state of a pin on the Raspberry Pi. The Raspberry Pi has a program running in the background which checks if the logic level on the pin has changed. If the logic level changes, the script will issue a shutdown command.

The next thing was to determine the best way to know when the shutdown was complete.

Soft Latching Power Switch

The Raspberry Pi ON/OFF Power Controller that I looked at from Mosaic Industries, Inc. does a good job at 5 VDC but I need the circuit to be able to switch LiPo batteries which have a voltage range of between 2.7 and 4.35 VDC between discharged and fully charged. I looked for dual MOSFET devices which could operate in this range and found the following.

Both of these devices function at these lower voltages however I have been having some oscillation issues with these. When the button is held down to turn off the load, which is a LED, the output is switched off but it turns back on after a few seconds. I have not been able to investigate why this is happening. I suspect that I miswired something but I need to take some time to check.

The International Rectifier device seems to behave a bit better so it may be the one I use but I will need to investigate what the issue is and resolve that before I can move on. I can’t wait to wrap this project up.

If you have an idea as to what my problem may be, please leave a comment to let me know.

UPDATE – 16 May 2015

I determined the reason for the odd behavior was that the N-Channel MOSFET’s gate was floating. I was able to fix this by using a pull-down resistor of 100KΩ. Looking at the schematic, I connected the resistor between Pin 7 and ground. This pulls the gate to ground through the 330KΩ and 1KΩ resistors.