Teensy 4.1 Based CNC Controller

Thanks Phil.
I will have to read up on the configuration architecture in grblHAL. I see that there are several different ways of configuring a machine.
So far I was able to get around the alarm state and send a few G1 codes to the board using the ioSender. Everything seems to be working.
Tomorrow I will hook up two steppers to check it out further.

What you mentioned about the ioSender brings up an interesting topic.
My plan is to use a Raspberry Pi to control 2 separate Teensy CNC controllers by sending G-Code commands from the RPi to each Teensy via the RPi's USB ports.
I program in Python and was going to use the PySerial library to push out the G-code commands to the USB ports.
Something like the following; https://onehossshay.wordpress.com/2011/08/26/grbl-a-simple-python-interface/
Can this approach work? Or, is the communication protocol with the Teensy CNC board so complicated that I have to use a software package like the Universal G-Code Sender or terjerio's ioSender?
 
Yes, that certainly can work. The communication protocol for grblHAL is basically the same as the original Grbl with a few additions. You will want to read up on streaming data to Grbl it can run at full speed. The original Grbl wiki has a good section on this. The note in the code you linked to talks about that as an optimization. Also, the discussions section of the grblHAL repository is a good place to ask questions about it. The guy that wrote ioSender is there and very helpful.

By the way, I have a number of customers that are running UGS, bCNC or CNCjs on a Raspi. I've tested UGS and bCNC on a RasPi, seems to work ok though I have not built a machine with it. UGS also supports connecting via Ethernet.

And, ioSender is open source, written in C#.
 
Last edited:
Elf said:
Will a Teensy 3.6 work with this board?
Click to expand...

Two answers to this question:
- The board will take a 3.6 as it has the power/gnd/Serial/I2C pins in the same locations as the T4.1. I haven't tried it, though. It will not work for ethernet, though.
- The CNC software, grblHAL, does not work with the 3.6. It probably would not be hard to port though. Mostly needing timer changes, I think. grblHAL is designed from the ground up to be portable. The team is currently working on Pico port to make it the 14th (I think) microprocessor supported.
 
Is there a version of schematic available which allows me to search signal names?

I'm trying to apply this to a custom-built lathe. I certainly appreciate the schematic, but in JPG form it cannot be searched. I just want to be sure I'm not misusing some signals.

I have the older version schematic in Eagle format, but since the Teensy versions are different, I'm sure the I/O is quite different, too.

Lastly, given that the Teensy has USB built-in, is it true that the Ethernet-based board can be used as either USB or Ethernet (with respect to grblHAL)?
 
GaryCNC said:
Is there a version of schematic available which allows me to search signal names?

I'm trying to apply this to a custom-built lathe. I certainly appreciate the schematic, but in JPG form it cannot be searched. I just want to be sure I'm not misusing some signals.

I have the older version schematic in Eagle format, but since the Teensy versions are different, I'm sure the I/O is quite different, too.

Lastly, given that the Teensy has USB built-in, is it true that the Ethernet-based board can be used as either USB or Ethernet (with respect to grblHAL)?
Click to expand...

The I/O on the current board (V 2.09) is pretty much the same as earlier versions. I will put up a schematic of it on github. [edit: here ]

Yes, you can use either USB or Ethernet to communicate with the Ethernet version of the board. In fact, you need to use USB to get (and/or set) the IP address. UGS and ioSender support Ethernet connection (via Telnet).

You will probably want to use the digital inputs - S0-S3. These are low pass filtered (15.9 kHz), Schmidt triggered and diode protected. Note that they do not connect to pins on the iMXRT1062 that can be used for HW quad encoders. I have a new "Pro" version of the board I am working on that moves the pins to support HW Quad Enc.

Note that currently there is no driver that supports spindle sync.
 
Thanks for the response.

I think initially this will be just fine. Eventually, once I get my head wrapped around the code, I'll look into adding some things.

I'm using servos so I can bring their error signal back into the regular inputs. For the spindle, I'm driving it with a 4HP servo, so I can thread using regular gcode by advancing Z while turning C.

But I would prefer to sync a less expensive motor so maybe that's what I'll look into as my first effort here.
 
I look forward to seeing the results of your efforts.

A number of my customers using servos bring the error signal into EStop. There is a movement to bring out another input signal - Servo-Alarm on an unused Limit switch input (like B on a 3 or 4 axis machine) and give you a better sense of what happened. Should work with the current board.
 
ORing all the servo error signals together into EStop would work.

BTW, Is there any reason that JP11 can't be fed with 24V ?

I can share a GND somewhere with my 24V supply since JP11 doesn't have a GND, but it looks to me that JP11.2 could be driven with 24V. All the relays I use, including pneumatic solenoids, are 24V.
 
Your servo error outputs will need to be open collector. Most of the error outputs I have seen are OC and pull the signal low on an error. If you want to wire OR them, you will need to set the EStop input to NO.

Yes, you could feed the relay voltage line - center pin JP11 - with 24V. The ULN2003 is rated higher than that. You could use the +12V terminal's Gnd since it is close by but any ground terminal will do.
 
Hi Phil,

I have mounted the board on a 3D printed carrier thingy using some standoffs (3mm screw size). I am still prototyping hence the plywood backboard.
What I noticed is that one end of the board is pretty tight to put screws thru (unless I screwed up the soldering of the terminals).
The Philips head screws I used on the other end of the board would not fit. So I used a socket head cap screw (3mm). Yeah, total overkill but I did not have any other M3 thread screws I could use on the standoff.
An extra 1/16" of space would be great I think. Or may be even 1/8". Or any advice you might have for this noob.

I am really happy with this product so far. I have tested the Z and A axes together. Then X and Y axes together. This weekend will test all 4 axes together in a coordinated fashion.

Here are some photos;
https://imgur.com/a/SoUn8Qc
 
Yeah, that one corner is a bit tight. When I designed the board, I used 4-40 screws to model against. They clear tight but ok. Other screws like M3s are a little bigger. I have since moved to M3 spacing because of that. Screw terminals take up a lot of space. Sorry for trouble.

Glad to hear it is working well otherwise.
 
I have ordered 2 PCBs because i was not able to get some parts here in Germany.
Lets see how long they need to get here ;-)

One of them is going to control a little china lathe, as the motor and his controller work well I am not going to change them.
But specially for threading a hall sensor would be necessary to adjust the speed of the axis to the existing RPM of the motor.
Is this possible at all? Did not see such an input in your GitHub, or is there another solution for this?

Superb work BTW ;-)
 
Yes, I got your order. Thank You. Will ship tomorrow. Shipping times to Germany generally take 10-14 days.

Yes, it is possible. You may need to make modifications to the board for spindle sync. Described here. (2 cuts and 2 jumper /bodge wires) There is another person working through this right now and has successfully cut threads on a CNC converted Emco lathe.

Also, I am close to releasing a new "Pro" version of the board that, among other new features, supports spindle sync without having to make modifications. Contact me via Tindie if you want to change your order.
 
You must log in or register to reply here.
Back
Top