Teensy 4.1 is coming.

[phil-barrett]

They have locked down the design and are in the process of qualifying suppliers so it's probably 2-3 months away. Of course the Corona virus pandemic may cause disruptions. It will use the IMXRT1062 and be in the same form factor as the teensy 3.6. All the T4.0 back side pins will be moved to TH pins so it's very likely that the Teensy4 GRBLHal will run without changes. The interesting thing is it appears it will support ethernet though it's a little unclear exactly what that means. Hopefully not via backside pins.

I'm hoping to get on their beta list though probably will not happen because you have to be a fairly active participant on the their forum. Hoping my breakout board for T4.0 will change their minds. By the way, my BoB seems to be working fine. Still a few things to test (0-10V generation) but very optimistic.

[terjeio]

Interesting. Running FreeRTOS and LwIP for Ethernet...?

Great that your BoB seem to be fine. Have you tested the EEPROM yet?

I am still struggling with the USB stuff, by now I suspect my USB hub is also part of the problems I have. No way I could get MKRZERO to behave with my development machine, but it seems to run ok with the laptop. More testing tomorrow...

[phil-barrett]

Have not tested eeprom yet. Are there any issues using other that the 24LC16B? I have a 24FC256 which has the same pinout and, I believe, same command set.

Paul didn't post a lot of detail and his ethernet support comment was in response to a question.

Yeah, I've never met a USB hub that didn't cause some sort of problems. By the way, after looking at the Due and doing a preliminary layout, I probably won't do a BoB for it and instead considering one for the ZERO. I had forgotten how much I hate the big Arduino form factors, especially the Mega but even the Uno is like an ugly, bitchy sister. What a mess.

[terjeio]

24LC16B is not command compatible with larger EEPROMS, it picks the page to be accessed from the I2C address and uses a single byte address within the page. Larger EEPROMS responds only to a single I2C address and uses two address bytes to access data.

It is on my todo list to add generic support for larger sizes, I have 256Kbit on hand for testing - but I need to make a breakout board first since it is a SMD device. First step is already done, as I've moved EEPROM code to the plugins folder.

FYI, I tested the MKRZERO with the 10hrs job overnight and it completed ok. However, I still have some issues remaining with the sender - maybe I need to rewrite the state handlers. A complicating factor is that many grbHAL drivers supports manual tool change. It is possible to jog when a program is halted for a tool change - this to allow for manual re-zeroing of Z. It should also be possible to execute a probe sequence in this state, all this without upsetting the senders internal state with regard to the running (but halted) program.

I am no fan of the Arduino stuff either, especially the lack of a debugger is a big pain. I do not use the IDE editor either...

I've attached a PCB drill file with tool changes if you want to check out how that works:

Prototype-drill.nc.txt

[terjeio]

I've added support for larger EEPROMs, use #define EEPROM_ENABLE 2. EEPROM plugin code needs to be updated for that.

Also, I have added a second option for serial over native USB (PJRC driver) - but this still fails for me.

[einencool]

Today I ordered a Teensy 4.1 It should be delivered this month, when I can trust the webshop g Is it also possible to use the "Ethernet" Shield or something like that? My laptop has only 2 USB Ports and one of them is having trouble with a stable connection... @phil-barrett I hope I can test your new BoB in the next month :-)

[phil-barrett]

I ordered one too. I have the layout done and have reworked the relay section to support both directly driving relays and TTL signals for things like SSRs and those Chinese relay boards. I also cleaned up the stepper enable signals and support up to 5 independent enables. Added direct control of dust extraction. It can be triggered off the spindle control or via a header with a switch attached.

My plan is to test the T4.1 via solderless breadboard and validate the BoB design, then manufacture the PCB and test. So, you will probably see it sometime in June.

[phil-barrett]

As to ethernet, I don't think it will ready to use right away so I haven't added it to the BoB but am planning a version that connects directly to the T4.1 header pins. with the magjack connector - essentially integrating the OSHPark adaptor mentioned on the PJRC page.

[edit] Also, I am hoping that with an ethernet version of grblHAL that the USB connector can be used to connect to a USB MPG/Pendant. but that's probably farther out.

[terjeio]

If a lwIP driver is available then it should be fairly easy to add ethernet as I have made a plugin that is currently used for 3 different controllers.

[phil-barrett]

Well then, it sounds like a possibility. https://forum.pjrc.com/threads/60532-Teensy-4-1-Beta-Test?p=237096&viewfull=1#post237096

[phil-barrett]

I think that I will just integrate the MagJack onto the first version of the T4.1 BoB. It looks pretty easy. Should have a design done later today. My T4.1 has shipped so I expect it on Thursday. I'm looking for a supplier of the MagJack as Mouser, my preferred disti, is out of stock and won't have any until June. I probably just send the board off to the fab without any ethernet testing.

I have chosen a naming convention that goes "processor" "connection" "num axis" BB so, the 4 axis T4.0 board is T4U4XBB and this new one will be T41E5XBB. [edit: sorry for the gibberish previously, ran into markup language problems.] I am also considering getting a version with all the SMD components manufactured, sort of an "un-kit". Just add the TH components. Thinking it would price in the $25 USD range. I'd still put the basic PCB design into open source, though.

[einencool]

Wow, you both are amazing 👍 I am so thankful that you are able to set up such projects

[terjeio]

to support both directly driving relays and TTL signals for things like SSRs and those Chinese relay boards.

Are there room/pins available for two inputs from an encoder? For lathe spindle sync (threading).

[phil-barrett]

Yes, there are pins available. I'll take a look. Are there any specific needs or issues I should be aware of? What commercial BoB/Controllers should I take a look at? I assume Linux CNC is the model you are following.

[terjeio]

Are there any specific needs or issues I should be aware of?

Preferably one pin should be routable to a counter clock input, I'll check the docs tomorrow.

What commercial BoB/Controllers should I take a look at?

I do not know, and I do not know if it is relevant. If at some point tapping is implemented perhaps 3 pins are needed so that spindle direction can be determined too... Quadrature encoder input + index input.

I assume Linux CNC is the model you are following.

Yes, that is the basic spec I try to follow. But not every detail is possible to implement in firmware.

If I can get spindle sync to work properly and port that to T4.1 then IMO this may become a good selling point for your board. For now I have one remaining issue I am struggling with which baffels me big time - with luck I just spotted where it originates. More testing tomorrow. I am using a PID loop to control the position, and if I've coded this right then the accuracy in the control loop in the ±20 µm range...

[phil-barrett]

Thanks. It sounds like it's not really direction that is needed but an index pulse - one gets direction from quad-encoding. Anyway, good news, I still have 4 pins open and they all are interrupt capable. One issue - I am running out of connector space on the edge. Would a pin header be acceptable instead of a screw terminal?

[terjeio]

A pin header is acceptable, 5 pins? 3V3, PHASEB, PHASEA, INDEX and GND in that order?

It seems that you are free to use the pins of your choice, from chapter 60 in the reference manual:

The intended application of this module is to provide a flexible crossbar switch function that allows any input (typically from external GPIO or internal module outputs) to be connected to any output (typically to external GPIO or internal module inputs) under user control. This is used to allow user configuration of data paths between internal modules and between internal modules and GPIO.

[phil-barrett]

No problem.

Will do after I'm done fighting Eagle's differential pair routing. How well does KiCad do that? Maybe it is time to make the move.

[phil-barrett]

Questions as I look into it more. These pins need to be isolated - via optoisolators. What level of RPM do you expect? The optos I'm using are good to about 25KHz. Can you give me a link to the data sheet for your encoder?

Also, you mention 3.3V - is this enough for most quad encoders? I've seen some that say 5V. Perhaps I should make the supply voltage configurable.

[terjeio]

How well does KiCad do that?

I do not know since I have not done any differential routing. Google "kicad differential routing" for some leads like this. Forum members are friendly so they may help out if you encounter problems.

Can you give me a link to the data sheet for your encoder?

It is homemade - optical, 120 PPR, no quadrature as I do not need that.

My thinking is that the port should be at 3.3V and level shifters should be added by the end users if required. IMO bit dangerous to put 5V there (configurable is ok?) as it could be easy to fry the processor by the unaware. I have not checked the dynamic specs for the ENC peripheral, but I guess it can handle input pulses in the MHz range, the TM4C123 QEI peripheral surely can.

[phil-barrett]

I'm using optoisolators, there's no danger to the processor. Could be to the encoder if the voltage is misconfigured, though. Not sure how to prevent pilot error.

If your motor is running your encoder at 3000 RPM, then that is 6KHz so my LiteOn optos (LTV 8x6) will do just fine. I've seen encoders that have upwards of 1000 PPR which would overwhelm them. Fortunately most applications don't have super high RPM.

Is your encoder able to drive 5 mA? My optos will work with less but I like a little extra margin.

[terjeio]

My encoder uses optocouplers already (slotted, there are holes in the disk for creating pulses). So I do not worry about that. BTW I have an open drain FET on the output capable of sinking 200mA.

I've seen comments elsewhere from people CNCing their lathes and using encoders supplying up to 4096 pulses/rev. AFAIK some (most?) are optical, at least quadrature encoders - and some uses Hall elements. I do not believe many are purely mechanical. IMO it is not easy to provide a generic isolated interface for them.

I did a quick google of "lathe spindle encoder" there is a bewildering array of different styles...

I do not what kind of inputs commercial controllers provides for spindle encoders. I use a SmoothStepper with Mach3 - and I had to make a BOB for that as there is no optocouplers on-board. If I want to add an encoder I have to provide a level-shifter and/or isolation if so required.

[terjeio]

A nice device to put on the encoder inputs could be the 74LVC1G17, a Schmitt trigger with 5.5V tolerant inputs. In my chase to track down my lathe problem I made a new encoder design using them.

The lathe problem turned out down to be the power supply, I was triggering the overcurrent protection randomly during cutting moves, but not during rapids - losing (or gaining?) steps. Reducing stepper current a bit solved that and subsequent tests of G33 spindle synced cuts lined up perfectly.

A bit more work on the lathe project and I will be ready to spend some time on the T4 driver and the sender. It would be nice to get spindle sync and Ethernet implemented for the T4.

[phil-barrett]

I love tiny logic and have an OR gate on the new board. Will have to take a look, see my comments at the end of this message. Just finished up the T4.1 board including the encoder inputs. Here's what I have so far on that. Schematic first. Inputs on the pin header to the left. Connections to Teensy pins on the right. Ignore the 10K value on the resistors, will probably be 330. The header on the board: Voltage config via a solder jumper on the bottom side of the board:

Adding 3 schmitt triggers isn't hard. Would have to put it between the pin header and the opto inputs. I'm not sure I see the benefit, though. An ST is good for slow moving analog signals. I think encoder outputs are fairly crisp. Is that not correct? STs also help with noise though optoisolators do too. I've got a couple of different encoders here. Will take a look with an O'scope to see how they behave.

[terjeio]

What is the RL on the optocouplers? Only MCU input pullup? If so the frequency response will likely be really bad... See page 12 of the datasheet. MCU input pullup resistor values are typically around 50K - not sure what the typical IMXRT1062 value is, didn't find it after a quick check.

The output of my spindle encoder is (or rather was) close to a sine wave, it is ok too feed that to a MCU input if it has a Schmitt trigger embedded. MSP432 has as standard, for IMXRT1062 it seems to be optional and configurable, ref 11.4.2.1: "Selectable Schmitt trigger or CMOS input mode". Something to keep in mind when adding driver support.

Since you decided to keep the opto-isolators it would be helpful to specify the max usable pulse rate. And also the minimum drive current required for the diodes unless you decide to put a Schmitt trigger in front of them - if you do so you do not load the encoder outputs too hard and can control the diode current yourself.

[phil-barrett]

OK, so maybe that's not going to fly. The 1062 has configurable pullups but they are pretty weak. I'm worried about a noise path into the digital section of the system. Maybe a low pass filter with an appropriately chosen cut-off frequency would work. Figure 50 KHz range?

Good point on the 1062's configurable inputs for ST - I will need to spend more time on that.

[terjeio]

OK, so maybe that's not going to fly.

Well, just adding a resistor (in parallel with the pullup) will help a lot - then you may keep the optos. Here is a PWM to voltage converter I made for the spindle VFD I use for the lathe:

As you can see I drive both the photodiode and transistor quite hard, this in order to get a acceptable frequency response.

Still I am of the opinion that 74LVC1G17 on the inputs and no optocouplers would be a good compromise. Just add a pullup resistor on the input Schmitt trigger in case the encoder output is open collector/open drain. IMO leave it to end user to provide additional circuitry if required. But do as you please, do not listen too much to me as I do not know what the appropriate choice will be...

I took a quick look at the spec of some spindle encoders I googled - I see some have differential outputs. Nice to have in a noisy environment.

[phil-barrett]

Since I've never used a spindle encoder on a motor, I don't have a good sense of the requirements. In the land of the blind...

Anyway, I'll probably use a low pass filter with a 30-50KHz or so cut off freq. I see the point of schmitt triggers here though. Considering setting up 4 ST inputs for general use. May use 2 SN74LVC2G17s - a dual gate version of the 1G17. The user can select a capacitor to meet their input frequency requirements or leave it off.

I still need to do more research on encoder inputs in CNC work.

[terjeio]

I still need to do more research on encoder inputs in CNC work.

Same for me. A good reason for not complicating this too much initially? FYI for IMXRT1062 filtering can be done in hardware, se section 55.8.3 Input Filter Register (FILT).

The number users that will need the encoder input for a lathe is low to none? Perhaps making use of it as a MPG input as well could be attractive? Use the index input pin to toggle between the axes? I could add a plugin for that.

[phil-barrett]

Yes, an MPG is fairly high on my list. However, I'm thinking the Host USB interface on the T4.1 is more attractive as it can support all those USB based MGPs out there. I think that's more work but ultimately a better solution. I've been meaning to talk to you about it. For the hardware, all I need to do is add a USB connector. Then it's a "small" matter of a grblHAL driver. With an ethernet interface, the PC may not be right next to the mill/lathe/... so an MPG plugged into grbl makes a lot of sense. On my list to investigate.

Also, I have looked at using an MPG via the keypad interface. I've programmed a Teensy 3.2 (could even be a Nano...) to read the encoder and buttons of an MPG I have and act as an I2C slave to send encoded "keys" to grblHAL. It's a bit rough at this point and was more of a learning exercise for me but it works.

Anyway, to get back to the input issue. I've got 2 2G17s and low pass rc filters for 4 schmitt trigger inputs designed in. Will go with that for now as I want to get moving on the ethernet interface. If it's not right, c'est la vie.

By the way, which version of the 1062 manual are you looking at?

[terjeio]

By the way, which version of the 1062 manual are you looking at?

Document Number: IMXRT1060RM Rev. 1, 12/2018

... act as an I2C slave to send encoded "keys" to grblHAL.

FYI: I am going to change the strobe input to active low with pullup so it can be wire-or'ed. This means that the pin driving this input should preferably be open drain - never drive it high.

[einencool]

Hello, today I finally got the Teensy 4.1. And then I remembered a software called „EstlCam“ and there are some special features that I wanted to ask, if it is possible to add in a simple way. It has a Potentiometer to set the Speed/Feedrate of the Program without pressing some Software Buttons. Especially in the beginning of a new GCode, sometimes it would be great to lower the speed of the machine, and if the first moves are ok, then the speed can be reraised to 100%.

Maybe you say: „Oh, that‘s very easy“ :-) https://youtu.be/RE86ogmF0Vs

[phil-barrett]

I watched the video. Mein gesprochenes Deutsch ist nicht serh gut. Did not understand all he said but... The panel with the two buttons and control knobs is separate from estlcam. It probably plugs into the sender PC. I think most senders can override feed rate in the UI. Spindle speed is possible from the VFD (or other speed controller), if present. It would be possible build a panel like that as a plug-in to grblHAL. It would be run by a small microcontroller (even an arduino nano could do it) that sends messages to grblHAL via the keypad interface. Essentially, it's an MPG/Pendant type device.

[einencool]

Hi Phil, Wow, I didn‘t know that you can understand and write in German, Respect 👍

This Panel plugs directly to the Arduino Mega or the Arduino Nano. The Arduino Uno doesn‘t have the right pins with an analog signal input.

Here you can see the wiring http://www.rc-network.de/forum/showthread.php/719360-Bedienpanel-ESTLCAM-Verkabelung

Drehzahl = Spindle speed Vorschub = Feed Rate And the two buttons with Start and Stop

:EDIT: The Arduino which will be connected is with the EstlCam Software the Arduino which controls the complete CNC machine. It‘s not a second Arduino.

[phil-barrett]

Ich versuche es, aber dein Englisch ist besser als mein Deutsch...

Yes, it took me a little time to understand that Estlcam is a complete controller too.

The stop and start buttons are directly available in grblHAL (and plain grbl, too). Drehzahl and Vorschub are not. So something would have to send those commands to grbl (or the G-Code sender) or the spindle controller (VFD or similar) - that's the MPG/Pendant approach I mentioned above. Terje's GCode Sender does this pretty well (as do other senders). I prefer that approach - less hardware to fail.

So, it's possible but not terribly easy.

[terjeio]

The only way to change the spindle speed or feed rate for grbl on the fly while running a program is to issue real-time override commands. I could add shortcuts for the buttons in my sender, but not sure this is a good idea as there are 13 of them... Any ideas for that?

I have a "potentiometer" (I am repurposing Menu encoder for that when the DRO canvas is visible) for setting the spindle speed from my MPG prior to starting a job, but I have not yet implemented any overrides. Cycle start and Feed hold has physical inputs so easy to wire up.

The I2C keypad plugin can be extended to support real time changes of the overrides even when a job is running. Flood and Mist overrides are already assigned keycodes.

So there are a few options available for expansion, even a secondary input stream could be used if limited to real-time commands when grblHAL is not in "MPG mode."

"MPG mode" is a grblHAL concept - a secondary input stream is needed as is an input pin for switching MPG mode on/off. When on the sender UI is disabled for input and passively listen to the data stream in order to keep itself updated. More info at the link above.

A commercial MPG could use the MPG mode concept with an appropriate firmware driver.

Note that I have not yet added MPG mode to the Teensy driver.

[einencool]

Ok, i have to understand ;-) I just thought, that it would be a great feature to start the job with a low feedrate, and when everything works fine, just bring it back to 100%. The spindle speed is for me not necessary, and the Start, Hold and E-Stop I’ve already wired up.

In our company we have a 3d CMM and there we also use the feed rate adjustment every time... I thought with this peace of hardware it could be very easy to apply, but it seems there is a lot more to do than i thought 💯

[terjeio]

... but it seems there is a lot more to do than i thought

Not neccesarily, but it needs to be done in some way or another. I have in fact updated the grblHAL core for accepting a quick succession of override commands in order to support potentiometer style adjustments by buffering them. The original grbl code does not. I did this for my MPG but it implementing it there is on some long forgotten todo list.

[einencool]

Hi Phil, Did you have the time to make some tests with the Teensy 4.1? Do you think it would be possible to add the potentiometer for the feed rate adjustment? In my opinion it would be a great feature for the machine and would be also a big advantage to choose the Teensy and the grblhal :-)

[terjeio]

@einencool : I think it is better to use the spindle encoder input, analog input from a potmeter is IMO not a good choice. Encoder input may also easier to handle since it will be used to calculate which (relative) feed rate override commands has to be sent to grbl. And no analog noise to worry about.

Also, encoder input is easy to make relative to the current programmed feedrate - potmeter input is not. E.g. if feed rate override is canceled/changed by the sender what then to do with the potmeter? Move it to the appropriate position by using a motorized version?

When I find time I wil try using the Menu encoder on my MPG for overriding feed rate and spindle speed, encoders that has an additional switch (mine has) may be used to toggle between which override to change. The encoder index input can be used for that.

[phil-barrett]

Yes, I just got my 4.1 PCBs from China and will be building it up this AM. I have 4 digital inputs fed through 5V tolerant Schmidt Triggers. Currently the plan is for a 1Kohm/10nF RC filter which gives a cutoff frequency of 15KHz. Alternatively, I could easily do 48KHz (330ohm/10nF) or 1.5KHz (1Kohm/100nF). I could even leave off the caps if filtering is undesirable - it probably won't matter either way for manual input encoder.

And, yes, an encoder is the way to go on this. Not only is it more precise (potentiometers, especially low cost ones, are notoriously imprecise) but it is simpler and doesn't have to deal with noisy ADCs in a very noisy environment. Encoders with clicks are highly repeatable repeatable.

edit: here is the circuit for digital inputs. Sorry for the terseness - follow the wire lables to see the flow. The diodes are for protection and normally don't factor into the circuit operation. I will initially leave them out for testing purposes.

[phil-barrett]

A bit more updates on the T4.1 based design. It includes an ethernet jack which I hope to be testing soon.

I have been looking into manufacturing a PCB with all the surface mount components and it looks good. Found a manufacturer that can do small runs for a reasonable cost. I've had to change a number of components to work with what the manufacturer has available and will be doing a trial run of 10, probably next week. The design is ready to go once I have verified the PCB, A user would install the through hole components (headers and terminals mostly) and the T4.1. I'm targeting less than $30 for the "unkit" board.

[phil-barrett]

ugh. missing parts to assemble. I modified the board to use smaller footprint capacitors and had ordered them a while ago. Unfortunately the package won't get delivered until Tuesday (not sure why it was so slow). I can make some progress but full eval won't be done until then,

[einencool]

Thank you two for the fast responses :-) As you know, my knowledge about electronics is not so good. When someone tell me, what to do, then it's not the Problem to solder some parts together :-), but like the digitl inputs, I have NOOO idea what I should do with it g

But it would be great, when it would be possible to adjust the rates with the Hardware which I can install directly to the machine, without going to my laptop which is standing 2 meters next to the machine.

Last week I wired up the Teensy 4.0 Board completly, with the vacuum cleaner and the mist coolant automated with the machine. That's great, and after the program is finished, I switch the button and can clean the machine with the vacuum cleaner. It works really good.

In the next time I'll try a little bit with the probing and maybe someday with the M6 commands.

Thank you both for all your great work

[phil-barrett]

Wunderbar! glad it's working for you. Would love to hear feedback on any changes or ideas for improvement.

[einencool]

Well, for now with the teensy 4.0 it’s all ok. You mentioned that you make a improvement for the switch for the vacuum cleaner. Thats one point for easier wiring. The A-Axis maybe can be used in the future for the second Y-Motor, but that’s nothing to change...

Then for me it would be great with the feedrate adjustment (in a way you both can support without problems ) and the network connection. Fortunately I’ll have to swap my laptop because it doesn’t have a network connection g I’m not so firm with the hardware and i don’t know, what is possible with the teensy, so if there would be a nice feature you can tell, let me know ;-)

[terjeio]

The A-Axis maybe can be used in the future for the second Y-Motor

I have ported grbl-sim to grblHAL (as a driver) with the intention to expand it into a test platform for features that is hard to test without access to a suitably configured machine. Auto squaring and probing are areas where this would be useful. I will publish the simulator with the next release of the grblHAL core, cannot do it for the current since I have made some optimizations to the planner that I need for the port. And also a fix for a bug that was obscured by another bug (both inherited from vanilla grbl) I fixed a long time ago that the port revealed...

One new feature for grblHAL that is now on my todo list is probe connected detection and protection - this could become a useful feature.

[phil-barrett]

That is interesting. I looked at grbl-sim. It makes a lot of sense to be able to simulate various CNC machines.

[phil-barrett]

Some good news, the ethernet jack on the PCB works with the T4.1. Some not so good news, the lwip port is rough and doesn't use RTOS.

[terjeio]

Some not so good news, the lwip port is rough and doesn't use RTOS

A RTOS is not needed, polling lwip can be done from the systick ISR, from a TI example:

//*****************************************************************************
//
// The interrupt handler for the SysTick interrupt.
//
//*****************************************************************************
void
SysTick_Handler(void)
{
    //
    // Call the lwIP timer handler.
    //
    lwIPTimer(SYSTICKMS);

    //
    // Tell the application to change the state of the LED (in other words
    // blink).
    //
    g_bLED = true;
}

Note that the lwIPTimer fuction is specific to the TI lwip port (port = lowlevel driver), a similar function is available in the T4.1 port?

It should be possible to use the MSP432E401Y implementation as a template for getting lwip up and running in grblHAL.

And if the networking plugin is used for the protocol layer (telnet and/or websockets) then code can be copied from the MSP432E401Y driver . Most of the code needed is wrapped in ETHERNET_ENABLE, TELNET_ENABLE and WEBSOCKET_ENABLE #if #endif blocks.

[phil-barrett]

Thanks. I'll probably be asking questions once I get farther into it.