RPi stepper driver and relay build log


#21

I’m not going to try to argue with Bob, what he says is true to a point. But just how far do you go when it comes to adding all possible footprints you think you might need one day? The fewer parts you put on the board the less costly it is to respin if necessary. But my comment was mainly intended for Adam who already seems to have unused relays and transistor outputs. He has now run out of IO and is already suggesting he trade the Pi for a Beagle Bone Black to get more GPIO. I just thought it was time to draw the line. :wink:

As for J28, all it does is allow you to write protect your EEPROM. My suggestion was to provide an expansion connector in addition to the EEPROM. At a minimum this connector should include power (5V) and GND as well as the I2C bus. You could also include any unused GPIO pins from the Pi. You don’t need to populate either of the EEPROM or expansion connector until you need them, but the EEPROM is likely to cost less than a dollar anyway.

As for the current J28 it is not necessary just connect the WP pin to ground. Of course you can also leave it if you want.

Also, I think you should move/copy the EEPROM to the other I2C bus (pins 3,5) as I believe the bus on pins 27, 28 are intended to be used for an auto-configuration EEPROM. Again you can leave it on the schematic and add the footprint to your board just in case you want to add it some day. As I don’t use the Pi I can’t tell you what’s required to be in this EEPROM, but an EEPROM on the other bus (3,5) would be free for you to use for your own purposes.


#22

Why did you change from supplying 5V to the Pi from your board to powering the Pi from it’s microUSB connector?


#23

Hi Rob,

I decided to move the Pi outside the saw housing and run the ribbon cable to the electronics enclosure (It’s right next to it). I did this to simplify video, Ethernet and USB connections as well as make it way easier to access the Pi and it’s SD card when needed. I found this to be a real pain at the present.

Thanks

Adam


#24

I’ll send some pics which may help explain. I found a nice aluminum pi case that will mate nicely to the saw housing (also aluminum). If I do another saw version I’ll Tig weld this case to the housing before powder coating.


#25

Whoa, that’s going to be some crazy heatsinking!


#26

Hi everyone, I’m tied up for the next 10 days and will work on this when I can.


#27

Fun project!!!

Not (strictly) hardware related, but I do have some experience with driving stepper motors using step and direction from a RPi. This looks like a very cool project, and I hope that I can save you some headache (and money, and time)!

There be dragons here!!!

First, some supporting material:

YouTube - First Video Showing Stepper Running
YouTube - Second Video Showing Position Error Testing
GitHub of Stepper Driver Code using RTLinux

I was doing this project for a friend who works at a university and needed a lab testing machine for tissue samples. He wanted to use Linux as there would be onboard data collection using scientific Python, etc.

Since I make industrial boards for the RPi and do motion for my day job, I thought this would be a slam dunk.

Short story - no.

I knew the project was aggressive (direct driving RPi GPIOs to 40+ kHz, cross-compiling and using Real Time Linux, writing a motion controller from scratch, etc), but ultimately, I had to pivot and use a standalone controller from one of the companies I represent (I communicate with it over Modbus/TCP).

Why?

Even using Real Time Linux (don’t even try without it), there is still 10-15us of jitter in the step output. After running exhaustive tests, I found that this was contributing to a cumulative position lag that was non-linear. Long story short, if you are driving your outputs at anything over 1 kHz, you are going to have position lag issues that will cause repeatability issues in the material that is being cut. Real Time Linux is good, but it is still an OS, and even in “real time” mode, it is not hard realtime like what you get out of a dedicated uC.

The better thing to do would be to put an intermediary uC in between the Pi and your stepper drivers. Program the motion controller into the uC using interrupts to form your square wave, and then command it from your host controller, the RPi, over serial.

Feel free to ask me questions! Also, feel free to borrow any of the stepper controller code in my Github. It is not complete, but it does work (I just stopped once I found out the direct drive RPi solution was a dead end) enough to show you the math behind driving steppers to execute a trapezoidal move. The code isn’t tested, so I am sure there are bugs, but at least it is a starting point.

You have a very cool project on your hands! Good luck, and let me know if I can help.


#28

Hi John,

Thanks so much for this information and will definitely be looking to pick your brain some more!

After a quick read, I’m not sure if this will be an issue for me in this application. I move a mm then make a cut, then move a mm then make a cut. I don’t need to move very quickly as the distance is small. I’m wondering what your thoughts are? I do have some other things I would to build where it seems this would likely be an issue though.

A few questions -

  1. I looked into the Rhubarb controllers can you provide a link? Any idea on cost?
  2. Can you expand on the idea to use a uC? Are you thinking something like an Arduino or more like a setup on the Rhubard? In concept, would this work by sending the number of steps required and the uC generating and sending the signal, or just the uC repeats the signal at a different freq.
  3. I can also change SBC fairly easily. Perhaps there is a better, simpler or more appropriate solution than a RPi?

All the best,

Adam


#29

Hi John.

So I dug into this some more and it seems it is common to use an Arduino nano loaded with GRBL or use the ATmega328 directly on the board. Does anyone on the forum suggest mounting the chip directly or better to have it on a socket? The Pi sends g-code which the ATMega parses and runs the steppers etc.


#30

Got my first PCBs back from allpcb.com today. These were simply small breakout boards for some micro-switch connectors. Any suggestions or feedback would be appreciated. Of note, the through holes are not plated and this was likely an error on my behalf somewhere in the process.


#31

Maybe just chose the single layer option? Not sure why they would have the two options when it is the same price.

How long did it take from order to delivery?


#32

I think choosing the single layer option was my mistake. I can use these but the it would have been nice to have the silk screen on one side and the soldering pads on the other.


#33

Took about 3 weeks. I went with regular mail. 5$ for the boards and 8$ for shipping.


#34

Does the board match the gerbers that you sent? Did you send both top and bottom gerbers?


#35

I think that sort of arrangement or using GRBL at all would be overkill for your project. The kinematics of your saw don’t require anything like that. Your movements are so small and I doubt you would ever even move more than one axis at a time so any talk of jitter or KHz step rates is rather moot.


#36

I sent top and bottom Gerbers but selected single sided board. I think that was the mistake.


#37

I you have sent this off to OSH Park, then them know ASAP? Their support crew are excellent at sorting these thing out. … speaking from expierience.


#38

Thanks Steve. This went overseas but I think the issue was my mistake.

All the best

Adam


#39

Is it generally ill advised to run traces that mirror (on top of each other in F and B Cu layers)? For example to carry current from a relay to the power bus. Each trace would be carrying the same polarity. I can post a picture if this is not clear.


#40

Picture might be helpful