Originally shared by James Rivera Ok,

General CNC CNC Routers
, ,
1

Originally shared by James Rivera

Ok, I’ve just about had it with my TinyG v8 dying during jobs. Any suggestions for a board to replace it? Must be able to drive the NEMA 23 steppers that came with my #OpenBuilds Ox CNC router from #SMW3D (now hobby-fab). Additional info: I’d like to continue using CNC.js, so my options seem to be boards that support Grbl or Smoothieware. Price is a concern, too. I have an Arduino mega with a RAMPS board and I also have some DRV8825 drivers, but I’m not sure if they can handle these stepper motors.

2

I have one of these, it is excellent, very well made, never let me down.

3

Hobby-Fab just started carrying this Raspberry Pi CNC controller. I haven’t used it personally but it looks good. The DRV8825s should be able to drive your Nema 23s just fine.

https://www.hobby-fab.com/raspberry-pi-cnc-hat?mc_cid=71daf3b37b&mc_eid=1b8f121b16

They also have the Gradus M1 Pro but I don’t know much about it:
https://www.hobby-fab.com/shop-by-hobby-parts/cnc-router-parts/cnc-electronics/cnc-controllers/gradus-m1-pro

4

xPro

5

Are you sure it is the tiny G that’s the problem I am running an Ox from SMWD and tiny G also. No problems, I am using ChilliPeper.

6

Check out the Buildbotics Controller: https://buildbotics.com/

7

@donkjr Yeah, I’m pretty sure. I’ve had these same problems with Chilipeppr. Perhaps my board is just flaky. Either way, I want something different.

8

@Joseph_Coffland that looks nice, but too pricey for me.

9

@SirGeekALot one more point, have you tried disabling your end-stops? Most folks I see have problems its caused by end-stop noise. If this is the case a new controller may have the same problem. I had to take care in how the machine was physically wired and grounded.
Does the end-stop limit lights come on when its stops.

10

@donkjr Do you see this with the hall effect end stops as well? I use hall effect exclusively on both my cnc and 3d printer.

11

@Hobby_Fab Of course! When I got your newsletter, the first thing I did was send that Raspberry Pi hat to my friend who’s looking for a controller. Unfortunately he’s savvy and has decided to use a ramps that he already has.

12

@donkjr I do not have any end stops installed…yet.

13

@donkjr What I’ve read is that Pull high, switch normally open (NO) on the end stops is more prone to false triggers due to electrical noise. Where as Pull low, switch normally closed (NC) is less/not prone to this. It also has the benifit? that if your endstop wires are “interrupted” then the end stop will trigger.

14

@Jeremy_Arnold @SirGeekALot

Here comes the soapbox, sorry for the really long post. Hope its worth your read.

The noise problem is not usually the switch/sensor itself… its the sensor wiring, so the type of switch may or may not matter.

I buy that pulling the input to the processor low is better than letting it pull high but it depends on other factors. If the pull-up resistor on the switch is a low enough value and enough current is drawn it can work as well. That said often these inputs cannot handle the needed current. I like to use low true for its fail safe properties as you point out above.

The main problem is that these switches are connected through a long cable to the input of a processor that runs at 3.3v. Yes there are noise filters on the input but they are often not enough.
Noise generated from motors can easily shift an end-stop signal during a transient at a frequency the filter is not tuned for. Processors are capable of seeing very short transitions depending on how the firmware is designed.
The second most prevalent problem is that poor grounding design can allow for signal level shifts between the sensor and the receiver. Long wires have transient characteristics that act like antennas or dynamic resistances the shift a signal off of its resting value creating a false signal.

Optical isolate’rs can be used in between the sensor and the processor. That will allow the sensor signal to operate at a higher voltage (5V) and give isolation. However the grounding on this board must also be properly designed. [I wish these controller board designers would build in the optical isolation and drive. Processor input/outputs are not designed to receive and drive lines directly and in high static environments the connected line can blow the inputs]

So the bottom line is that just pulling up or down inputs or changing sensor types is not sufficient for a noise free system. Often these things work but it is more likely because these changes happen to alter the characteristics of the signal, its wiring and grounding changes in a positive way.

I spend a lot of time over on the K40 Laser G+ with folks that have done conversions. The problem there is that the Laser Power Supply is +20,000 vdc @ +20ma which is a lot of energy. Conversions that are done without “designing” signal and ground circuits often have problems when the laser arcs, starts up or changes current rapidly. Digital signals and High Voltage is a worse case environment.

The sensor type, cable type, routing and termination all need to be “designed” for any hope of a noiseless system. Most folks view wiring and grounding as a static thing and focus more on the convenience of the builds wiring vs the dynamic nature of the signal paths at high frequencies. Grounds are signals to!

…
Here is my design regime. Using this on my OX and K40 conversion have resulted in noise free operation. This seems like a lot of extra work but it pays off when you have a quiet system that behaves predictably. Signal and ground integrity is as much an art as an engineering discipline, your results may vary *

*Signal path design:

  1. Whether pulling the endpoint up or down insure that the max amount of current is provided. You are trying to insure that low signals cannot be pulled up by noise and high signal stay high in the presence of noise.

  2. Wire the signal using twisted pair from one end to the other. Ground is on one wire and the signal on the other. The ground lead of the TP should be grounded as close to the source of the receiver as possible. Sometimes it works better to ground the receiver end at its extent but that is usually in extreme cases and requires trial and error. Cat 5 cables often have twisted pairs and makes a nice signal bundle. You have to strip them to tell. Do not run signals all together without TP in the same wire harness or bundle. I logically group my signals into CAT 5 cables. Its a lot more wire but its worth it. Shielded cable can also be used but it can create as many problems as it solves. Where to ground the shield is often a mystery and requires trial and error. I have not ever had to use it because most noise problems I have encountered are conducted not radiated.

  3. Route the input wire/harness as far away from high current devices as possible. Definitely do not run motor signals in the same harness as sensors whether using TP or not. I run my motors in a totally separate harnesses. The big offender here is the spindle. Having signal wires even close to the spindle drive or its 48VDC power connection is asking for trouble. Consider that these wires (both supply input and motor load) endure large and high current transients in the order of 10+ amps.

Grounding Design:

  1. The ground system design must consider the path the current follows to get back to the sources driver (that’s usually the device on the PCB). Signals that are a long way away that are not grounded back to the source can experience ground shifts when exposed to strong transients due to line inductance, and voltage drop etc. The distance that the current has to travel can have a profound effect on the signal voltage seen at the receiving end of signal.
    As and example if a sensor is grounded out on the gantry the return current has to flow through the frame back though to the controllers ground lead across the PCB and to the input receivers ground. Unless the frame of the gantry has a beefy wire running back to the controller the ground path may not exist or even be conducted through moving ball bearings :(!
    This principle is true for the grounding schema for supplies as well.

  2. Power supplies should be wired directly to their load. That means two beefy wires (power and grnd) as short as possible directly to each load. The bigger the wire the better, size matters here. Do not run a PS’s wiring to one load and then daisy chain to others.
    Ground each power supply back at the supply’s terminal to a common gas tight connection on a common frame location. Yes I mean a single lug that all PS grnd lugs connect to. All supplies should literally have a beefy wire from the ground lug on the supply to the common frame lug.
    Tie the safety ground from the AC plug to this same common lug.
    I use a bolt with soldered ring tongues stacked with star washers in between each lug.

Admittedly this regime requires a lot of up front signal and physical planning and uses a lot more wire and likely more drag chains than you hoped.
I have found it to be worth it.

15

@SirGeekALot are they turned off? floating inputs can create problems.

16

@donkjr I’ll have to check the TinyG v8 firmware settings; not sure what to check offhand. It sounds like you’re saying there are 3 settings for each end stop: NO, NC, and OFF. My assumption was the default was OFF until the user added end stops. Perhaps this was a flawed assumption? But if there is no OFF setting, then it must default to NO or else would be always be triggered. But if default is NO and nothing is connected, I would think that would be floating, but (another bad assumption?) hard to trigger. I guess I need to find the $ settings for the end stop switches. Thanks for your input!

17

Son of a…!

Looks like I forgot that my “default” settings were copied from someone else. My end stops are set to HOME!! Grr… (slaps own forehead–HARD). Here are my settings, and sure enough, XSN, YSN, ZSX are set to 1 instead of 0!!! :frowning:

$$
[fb] firmware build 440.20
[fv] firmware version 0.97
[hp] hardware platform 1.00
[hv] hardware version 8.00
[id] TinyG ID 3X3566-3ZW
[ja] junction acceleration 2000000 mm
[ct] chordal tolerance 0.0100 mm
[sl] soft limit enable 0
[st] switch type 1 [0=NO,1=NC]
[mt] motor idle timeout 2.00 Sec
[ej] enable json mode 0 [0=text,1=JSON]
[jv] json verbosity 4 [0=silent,1=footer,2=messages,3=configs,4=linenum,5=verbose]
[js] json serialize style 1 [0=relaxed,1=strict]
[tv] text verbosity 1 [0=silent,1=verbose]
[qv] queue report verbosity 1 [0=off,1=single,2=triple]
[sv] status report verbosity 1 [0=off,1=filtered,2=verbose]
[si] status interval 250 ms
[ec] expand LF to CRLF on TX 0 [0=off,1=on]
[ee] enable echo 0 [0=off,1=on]
[ex] enable flow control 1 [0=off,1=XON/XOFF, 2=RTS/CTS]
[baud] USB baud rate 5 [1=9600,2=19200,3=38400,4=57600,5=115200,6=230400]
[net] network mode 0 [0=master]
[gpl] default gcode plane 0 [0=G17,1=G18,2=G19]
[gun] default gcode units mode 1 [0=G20,1=G21]
[gco] default gcode coord system 1 [1-6 (G54-G59)]
[gpa] default gcode path control 2 [0=G61,1=G61.1,2=G64]
[gdi] default gcode distance mode 0 [0=G90,1=G91]
[1ma] m1 map to axis 0 [0=X,1=Y,2=Z…]
[1sa] m1 step angle 1.800 deg
[1tr] m1 travel per revolution 60.0000 mm
[1mi] m1 microsteps 8 [1,2,4,8]
[1po] m1 polarity 1 [0=normal,1=reverse]
[1pm] m1 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving]
[2ma] m2 map to axis 1 [0=X,1=Y,2=Z…]
[2sa] m2 step angle 1.800 deg
[2tr] m2 travel per revolution 60.0000 mm
[2mi] m2 microsteps 8 [1,2,4,8]
[2po] m2 polarity 1 [0=normal,1=reverse]
[2pm] m2 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving]
[3ma] m3 map to axis 1 [0=X,1=Y,2=Z…]
[3sa] m3 step angle 1.800 deg
[3tr] m3 travel per revolution 60.0000 mm
[3mi] m3 microsteps 8 [1,2,4,8]
[3po] m3 polarity 0 [0=normal,1=reverse]
[3pm] m3 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving]
[4ma] m4 map to axis 2 [0=X,1=Y,2=Z…]
[4sa] m4 step angle 1.800 deg
[4tr] m4 travel per revolution 8.0000 mm
[4mi] m4 microsteps 8 [1,2,4,8]
[4po] m4 polarity 1 [0=normal,1=reverse]
[4pm] m4 power management 2 [0=disabled,1=always on,2=in cycle,3=when moving]
[xam] x axis mode 1 [standard]
[xvm] x velocity maximum 16000 mm/min
[xfr] x feedrate maximum 16000 mm/min
[xtn] x travel minimum 0.000 mm
[xtm] x travel maximum 290.000 mm
[xjm] x jerk maximum 5000 mm/min^3 * 1 million
[xjh] x jerk homing 10000 mm/min^3 * 1 million
[xjd] x junction deviation 0.0100 mm (larger is faster)
[xsn] x switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[xsx] x switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[xsv] x search velocity 3000 mm/min
[xlv] x latch velocity 100 mm/min
[xlb] x latch backoff 10.000 mm
[xzb] x zero backoff 2.000 mm
[yam] y axis mode 1 [standard]
[yvm] y velocity maximum 16000 mm/min
[yfr] y feedrate maximum 16000 mm/min
[ytn] y travel minimum 0.000 mm
[ytm] y travel maximum 320.000 mm
[yjm] y jerk maximum 5000 mm/min^3 * 1 million
[yjh] y jerk homing 10000 mm/min^3 * 1 million
[yjd] y junction deviation 0.0100 mm (larger is faster)
[ysn] y switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[ysx] y switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[ysv] y search velocity 3000 mm/min
[ylv] y latch velocity 100 mm/min
[ylb] y latch backoff 10.000 mm
[yzb] y zero backoff 2.000 mm
[zam] z axis mode 1 [standard]
[zvm] z velocity maximum 1000 mm/min
[zfr] z feedrate maximum 1000 mm/min
[ztn] z travel minimum -120.000 mm
[ztm] z travel maximum 0.000 mm
[zjm] z jerk maximum 50 mm/min^3 * 1 million
[zjh] z jerk homing 1000 mm/min^3 * 1 million
[zjd] z junction deviation 0.0100 mm (larger is faster)
[zsn] z switch min 0 [0=off,1=homing,2=limit,3=limit+homing]
[zsx] z switch max 1 [0=off,1=homing,2=limit,3=limit+homing]
[zsv] z search velocity 1000 mm/min
[zlv] z latch velocity 100 mm/min
[zlb] z latch backoff 10.000 mm
[zzb] z zero backoff 3.000 mm
[aam] a axis mode 3 [radius]
[avm] a velocity maximum 25920 deg/min
[afr] a feedrate maximum 12960 deg/min
[atn] a travel minimum -1.000 deg
[atm] a travel maximum -1.000 deg
[ajm] a jerk maximum 324000 deg/min^3 * 1 million
[ajh] a jerk homing 324000 deg/min^3 * 1 million
[ajd] a junction deviation 0.1000 deg (larger is faster)
[ara] a radius value 5.3052 deg
[asn] a switch min 1 [0=off,1=homing,2=limit,3=limit+homing]
[asx] a switch max 0 [0=off,1=homing,2=limit,3=limit+homing]
[asv] a search velocity 2000 deg/min
[alv] a latch velocity 2000 deg/min
[alb] a latch backoff 5.000 deg
[azb] a zero backoff 2.000 deg
[bam] b axis mode 0 [disabled]
[bvm] b velocity maximum 3600 deg/min
[bfr] b feedrate maximum 3600 deg/min
[btn] b travel minimum -1.000 deg
[btm] b travel maximum -1.000 deg
[bjm] b jerk maximum 20 deg/min^3 * 1 million
[bjd] b junction deviation 0.0100 deg (larger is faster)
[bra] b radius value 1.0000 deg
[cam] c axis mode 0 [disabled]
[cvm] c velocity maximum 3600 deg/min
[cfr] c feedrate maximum 3600 deg/min
[ctn] c travel minimum -1.000 deg
[ctm] c travel maximum -1.000 deg
[cjm] c jerk maximum 20 deg/min^3 * 1 million
[cjd] c junction deviation 0.0100 deg (larger is faster)
[cra] c radius value 1.0000 deg
[p1frq] pwm frequency 3000 Hz
[p1csl] pwm cw speed lo 0 RPM
[p1csh] pwm cw speed hi 12000 RPM
[p1cpl] pwm cw phase lo 0.063 [0…1]
[p1cph] pwm cw phase hi 0.085 [0…1]
[p1wsl] pwm ccw speed lo 0 RPM
[p1wsh] pwm ccw speed hi 10000 RPM
[p1wpl] pwm ccw phase lo 0.000 [0…1]
[p1wph] pwm ccw phase hi 1.000 [0…1]
[p1pof] pwm phase off 0.000 [0…1]
[g54x] g54 x offset 88.250 mm
[g54y] g54 y offset 439.250 mm
[g54z] g54 z offset -48.000 mm
[g54a] g54 a offset 0.000 deg
[g54b] g54 b offset 0.000 deg
[g54c] g54 c offset 0.000 deg
[g55x] g55 x offset 145.000 mm
[g55y] g55 y offset 160.000 mm
[g55z] g55 z offset 0.000 mm
[g55a] g55 a offset 0.000 deg
[g55b] g55 b offset 0.000 deg
[g55c] g55 c offset 0.000 deg
[g56x] g56 x offset 0.000 mm
[g56y] g56 y offset 0.000 mm
[g56z] g56 z offset 0.000 mm
[g56a] g56 a offset 0.000 deg
[g56b] g56 b offset 0.000 deg
[g56c] g56 c offset 0.000 deg
[g57x] g57 x offset 0.000 mm
[g57y] g57 y offset 0.000 mm
[g57z] g57 z offset 0.000 mm
[g57a] g57 a offset 0.000 deg
[g57b] g57 b offset 0.000 deg
[g57c] g57 c offset 0.000 deg
[g58x] g58 x offset 0.000 mm
[g58y] g58 y offset 0.000 mm
[g58z] g58 z offset 0.000 mm
[g58a] g58 a offset 0.000 deg
[g58b] g58 b offset 0.000 deg
[g58c] g58 c offset 0.000 deg
[g59x] g59 x offset 0.000 mm
[g59y] g59 y offset 0.000 mm
[g59z] g59 z offset 0.000 mm
[g59a] g59 a offset 0.000 deg
[g59b] g59 b offset 0.000 deg
[g59c] g59 c offset 0.000 deg
[g92x] g92 x offset 0.000 mm
[g92y] g92 y offset 0.000 mm
[g92z] g92 z offset 0.000 mm
[g92a] g92 a offset 0.000 deg
[g92b] g92 b offset 0.000 deg
[g92c] g92 c offset 0.000 deg
[g28x] g28 x position 0.000 mm
[g28y] g28 y position 0.000 mm
[g28z] g28 z position 0.000 mm
[g28a] g28 a position 0.000 deg
[g28b] g28 b position 0.000 deg
[g28c] g28 c position 0.000 deg
[g30x] g30 x position 0.000 mm
[g30y] g30 y position 0.000 mm
[g30z] g30 z position 0.000 mm
[g30a] g30 a position 0.000 deg
[g30b] g30 b position 0.000 deg
[g30c] g30 c position 0.000 deg
tinyg [mm] ok>

18

Changed all my end stop switch settings to 0, power cycled, and verified they are still set. Perhaps my frustrated comments towards TinyG were undeserved.

19

Nope. It crashed CNC.js on line 38 (even earlier than usual) of a job I’ve been trying to complete. I ran the serial port json server for Chilipeppr but when Chilipeppr tried to connect I got an access denied error. I’m back to thinking my TinyG v8 board may be flaky…

20

@donkjr Here is a picture of my setup. Do I need to build a Faraday cage around my control boards?!?