Experimental project to implement Rigid Tapping

[zombieengineer]

Just finished a long term project and think it is time to deal with the thorny issue of rigid tapping.

At this point of time MASSO has yet to implement rigid tapping as other stuff has been deemed higher priority (including the release of the MASSO touch - it has been on their "Todo list" that long...).

My thoughts were to take a servo motor and configure it for Speed / Position mode (mode selected by a digital input), wire the Z axis to the step/direction inputs and then use the "Electronic Gear" to perform the Z axis to spindle rotational scaling. Turns out that the electronic gear settings on servo motors can not necessarily be updated easily on the fly. For the Delta ASDA B2 servo motor the numerator can be dynamically updated on the fly, but the denominator can only be done while the servo is disabled (SON Digital Input = Low). The MASSO branded servo motors the parameter only becomes active after a power cycle (arrgg!).

My options at this point would be to perform the "Electronic Gear" outside the servo motor using a micro-controller or use an FPGA. Using the FPGA is the over-kill option as this would allow handling of pulse rates >10 MHz. The micro-controller option has some trade-offs, IO voltage levels versus CPU speed. The Arduino series of micro-controllers are largely 5V based but typically have a clock speed of 16 MHz (the Arduino Nano Every has a clock speed of 20 MHz). A clock speed of 16 MHz sounds much larger than the 100 kHz however each instruction processed by a micro-controller can take multiple clock cycles. Some bench testing will be required to see how fast an Arduino controller can process axis step signals. The ESP32 micro-controller is a 3.3V device (will require logic level conversion circuitry) but the clock speed is 160 or 240 MHz. The clock speed of the ESP32 may be sufficiently high that there is enough clock cycles to perform the electronic gear calculation on-the-fly.

One strange thing that came out is the spindle servo motor should have the same number of steps for a revolution as the Z axis requires to travel the distance of a single thread at the finest pitch that will be supported. Using this spindle step count means that the spindle will require the same step rate as the Z axis at the finest pitch, and a lower step rate than the Z axis at coarser pitches. Therefore with coarser pitches some of the Z axis step pulses will be dropped to achieve the correct step ratio (dropping a step pulse is easier than creating more than one step pulse for each Z axis step).

I am aiming to be able to perform rigid tapping for M3 to M6 threads and the UNC threads for equivalent diameters. The standard M3 thread is 0.5 mm while the equivalent UCN thread is 40 TPI (0.635mm pitch). My Z axis requires 1000 steps for 1 mm of travel, therefore 0.5 mm travel requires 500 steps => Spindle needs to be configured for 500 steps/rev.

In the next posting I will explain how the electronic gear works / implemented.

 

[tmtoronto]

Looks to be a great project - I will watch for your updates.
Is any of this content relevant

?

 

[zombieengineer]

@tmtoronto - Practically the Clough42 Electronic Lead Screw (ELS) would be able to do the job.

I managed to find the project Wiki (all credits to Clough42 for making this effectively open source under the MIT license):

Home

Lathe electronic leadscrew controller. Contribute to clough42/electronic-leadscrew development by creating an account on GitHub.

github.com

Key points I have found:

• Based on a Texas Instruments LaunchXL-F280049C prototyping board
• 100 MHz micro-controller, 3.3V IO, 1.2V core
• 100 kHz maximum step rate (which is likely to be fine for use with MASSO)

This provides a nice benchmark that suggests the Arduino Nano will not have enough processing power to achieve this (from memory the MCU for the Nano does not have a FPU), while the ESP32 MCU has at least the same functionality as the TI MCU but has a higher CPU frequency.

The ELS moves the Z axis in response to rotation of the spindle, while for rigid tapping I am intending to rotate the spindle in response to moves in the Z axis (basically turn on a digital output to enable rigid tapping and then perform a G1 move in the Z axis, the spindle will then rotate to match).

The ELS in its current form does not support remote setting of the desired thread pitch, this is something that will need to be considered (the required modifications for the ELS to implement this would not be to difficult).

The ELS uses an encoder with quadrature output while I am intending to use the Z axis step / direction as an input.

For the original purpose of a lathe electronic lead screw - the ELS project is very successful and again all credits to Clough42 and other contributors. However repurposing this for rigid tapping will require significant changes to the point where the ELS real contribution will be to provide inspiration on how it could be done.

---

Moving onto the description of an electronic gear, the following is how I intend to implement this:



From an implementation perspective, the electronic gear has an internal variable/register which is called the Accumulator. When a step signal arrives the Numerator is added to the Accumulator, when the value exceeds the Denominator then a step pulse is sent and the Accumulator value is reduced by the Denominator.

Using an electronic gear ratio of 5/7 results in the following step pulse sequence:



When pulses are dropped, only a single pulse is dropped and spaced evenly. When the ratio is less than 50% the output will become single pulses with gaps of one or more skipped pulses, however the pulses will be evenly spaced over the repeating span (typically the denominator number of pulses).

 

[zombieengineer]

The following is various thread pitches and TPI assuming a Z axis of 1000 steps/mm and a spindle having 500 steps/rev:

	mm/rev​	N1 (Spindle Pulses)​	D1 (Z Axis Pulses)​	Greatest Common Denominator​	N2​	D2​
Metric		500​	Pitch x 1000​
M3	0.500​	500​	500​	500​	1​	1​
M4	0.700​	500​	700​	100​	5​	7​
M5	0.800​	500​	800​	100​	5​	8​
M6	1.000​	500​	1000​	500​	1​	2​
UNC / UNF		500 x TPI​	25.4 x 1000​
40 TPI	0.635​	20000​	25400​	200​	100​	127​
36 TPI	0.706​	18000​	25400​	200​	90​	127​
32 TPI	0.794​	16000​	25400​	200​	80​	127​
28 TPI	0.907​	14000​	25400​	200​	70​	127​
24 TPI	1.058​	12000​	25400​	200​	60​	127​
20 TPI	1.270​	10000​	25400​	200​	50​	127​

N2 & D2 are the N1, D1 values divided by the 'Greatest Common Denominator'. The Excel Function GCD(X, Y) can be used to find the largest common factor of X & Y.

It should be possible to calculate the pulse sequence in advance to know which pulses will be skipped to reduce the CPU time for processing each pulse. The hoops we jump through to get the algorithm speed fast enough. Ahh... memories of programming in the late 1980's, not necessarily good memories.

Need to find a spare Arduino Nano, used one on my last project and fried another due to motor back EMF (suspect but can't prove it).

 

[zombieengineer]

I setup an Arduino Nano to do some "bit banging" to see what is achievable, managed to get to 147 kHz before implementing any other code (my oscilloscope shows a nice 50% duty square wave). This tells me that this micro-controller is a non-starter as any additional code to is likely to slow the system below the 100 kHz level. Test code below:

void setup() { // put your setup code here, to run once: pinMode(4, OUTPUT); } void loop() { // put your main code here, to run repeatedly: digitalWrite(4, HIGH); digitalWrite(4, LOW); }

 

[zombieengineer]

Found a YouTube video which explains how to improve the IO speed of an Arduino controller, now up to 2 MHz which gives a decent amount of margin for adding some code and still being faster than 100 kHz.

void setup() { // put your setup code here, to run once: pinMode(8, OUTPUT); // Set D8 (Port B bit 0) to OUTPUT } void loop() { // put your main code here, to run repeatedly: PORTB |= 0x01; // Turn bit 0 ON PORTB &= 0xFE; // Turn bit 0 OFF }

 

[zombieengineer]

A little bit of "old school" C programming and I now have an electronic gear running on an Arduino controller capable of keeping track with a 250 kHz step pulse rate. The following is for a 5/8 division ratio:



As the Arduino Nano is a single core MCU, it may be necessary to configure the controller to either run in standby mode where it can accept serial communications or running mode where it performs the step division.

The code for the above:
uint8_t PPD; // Previous PORTD values byte pulse_pattern[128], *pps, *ppe, *ppp; void setup() { // put your setup code here, to run once: pinMode(8, OUTPUT); // Set D8 (Port B bit 0) to OUTPUT pinMode(Z_STP, INPUT_PULLUP); // Set D3 (Port D bit 3) to INPUT with PULLUP resistor PPD = PIND; pulse_pattern[0] = 1; pulse_pattern[1] = 0; pulse_pattern[2] = 1; pulse_pattern[3] = 0; pulse_pattern[4] = 1; pulse_pattern[5] = 1; pulse_pattern[6] = 0; pulse_pattern[7] = 1; pps = pulse_pattern + 0; ppe = pulse_pattern + 7; ppp = pps; } void loop() { uint8_t PD = PIND; // Detect change of state for D3 if ((PD ^ PPD) & 0x08) { if (PD & 0x08) { // Turn output on based on pulse pattern if (*ppp) PORTB |= 0x01; // Turn bit 0 (D8) ON ppp++; if (ppp > ppe) ppp = pps; } else { PORTB &= 0xFE; // Turn bit 0 (D8) OFF } } PPD = PD; // Store previous value }

pps => Pulse pattern start
ppe => Pulse pattern end
ppp => Pulse pattern pointer

---

EDIT - I have modified the sketch to create the pulse pattern however the maximum samples is limited by available RAM (2048 bytes minus local variables). An attempt to dynamically calculate the pulse pattern to avoid the memory table resulted in a maximum pulse rate of about 20 kHz, it appears that numerical calculations of any kind are CPU cycle expensive.

 

[zombieengineer]

I will probably start looking at the ESP32 option however I found some references that state the minimum time for EPS32 to change a GPIO pin is 12 clock cycles while the AVR micro-controller in the Arduino Nano can do this in 1 clock cycle. Suddenly the ESP32 speed effectively drops to 20 million GPIO operations/second versus the Arduino Nano's 16 million operations/second. It would be nice to have the electronic gear algorithm calculated on the fly rather than using a pre-generated look-up table. Only testing will confirm the true capabilities of the ESP32 module.

One of the issues that I encountered with the Arduino Nano is the GPIO inputs have some inherit capacitance (perhaps due to something else) which becomes noticeable when you start approaching the 200 kHz clock speeds that the internal 10K ohm pull-up resistor requires some assistance in the form of an additional external 3.3k ohm pull-up resistor for an effective 2.5K ohm pull-up resistor. I was using a simple NPN transistor as an open collector for the purposes of triggering the input (the built-in signal generator in my osciloscope generates a ±1V square wave and I needed to convert this to 0-5V), the lag could be due to the transistor stored charge and the higher current helped the transistor to switch off quicker.

Interfacing the MASSO controller to a 3.3V GPIO system presents its own challenges. This morning was diving down the rabbit hole of logic voltage levels and different logic families. Wierdly the 5V TTL logic levels (<0.8V is considered Low, >2.0V is considered High) are the exact same voltage levels as used by 3.3V logic (the ESP32 documentation states <25% Vdd is Low, >75% Vdd is High. For Vdd=3.3V this becomes 0.82V and 2.48V)

The MASSO TTL outputs (including the side connector on any MASSO controller excluding the latest G3 Touch) are effectively 4.6V with 375 ohm impedance. The recommendation for converting from 5V Output to 3.3V Input is to use a simple resistor voltage divider. Crunching some numbers I came up with 3.3K ohm for the high leg (MASSO output => ESP32 Input) and 6.8k ohm for the low leg (pull-down resistor between ESP32 Input and signal ground). This should provide a reduced voltage between 2.99V to 3.25V (depending on the size of the voltage drop in the MASSO output circuit protection).

Transferring a signal from the ESP32 to 5V logic is where I encountered the logic family rabbit hole. Over the years there have been different logic switching techniques developed to reduce power, increase speed, etc. The following is a summary of what I encountered:

Logic Family	Input Current	Output Current	Speed (Typical)	Notes
7400 series	1.6 mA	16 mA	25 MHz	The original TTL logic family, today everyone uses something else...
74LS series	0.4 mA	8 mA	35 MHz	The default TTL logic family during the 1980s / 1990s
74HCT series	1 μA	10 mA	30 MHz	The "T" in the logic family name means the inputs are TTL compatible. The 74HC also exists but uses CMOS input logic levels
74ACT series	1 μA	25 mA	100 Mhz	The "T" in the logic family name means the inputs are TTL compatible. The 74AC also exists but uses CMOS input logic levels
4000B CMOS series	1 μA	3 to 5 mA	2 MHz	The MASSO TTL output uses a chip from this family. Inputs are not TTL / 3.3V compatible [*]
26LS31 (RS485 Driver)	0.1 mA	25 to 50 mA	10 MHz	TTL input logic levels, this is logic family of the chip used by MASSO for the axis output.

(*) The specific chip that MASSO used for the TTL outputs actually has TTL / 3.3V compatible inputs. In an industrial environment the 4000B CMOS series does not have enough output current for some inputs such as solid state relays (8 to 10 mA would be preferred).

The differential inputs of a servo motor are based around the RS485 standard (3.5V differential, 150 ohm load resistance, 15 to 20 mA current). As the output from the electronic gear module needs to drive a servo motor it would be best to use an RS485 driver for testing. Unfortunately these are not available from the local electronic stores (Altronics or Jaycar) so it means a delay while I source these.

Although in the past I have driven the differential input of my servo using the MASSO TTL outputs, the current is within the limits of the device (you can short circuit the output to signal ground without damage) but it is further than I would normally be comfortable pushing such a chip. There are some servo drives (Teknic stepper killer servos) that the MASSO TTL output does not have sufficient output current capacity to drive.

 

[zombieengineer]

First pass of the reviewing the ESP32 micro-controller as an Electronic Gear for the purposes of rigid tapping:

• Simple "bit banging" using Arduino digitalWrite() function call => 1.29 MHz (8.5 times faster than Arduino Nano)
• Direct "Fast IO" bit banging => 6.16 MHz
• Electronic Gear calculated dynamically
  • Initial code with no delays => approximately 4 MHz
  • At such speeds the signal did not peak to a flat line, more curved peak like a half sine wave
  • Added delayMicroseconds(1) which resulted in square wave but the speed dropped to about 200 kHz
  • Replaced delay with 16 _NOP statements to provide sufficient delay to see a square wave profile ( _NOP causes a 1 CPU cycle delay)
  • Leading edge to leading edge timing works out to be 2.67 MHz (currently 12 times faster than Arduino Nano)

Next steps are to:

• Input processing following an external step signal
• Investigate Interrupts and/or assigning a task to a core to allow parallel processing (such as serial communications and electronic gear without interfering with each other)

#include <Arduino.h> #define GPIO_NUM 16 uint32_t Numerator, Denominator, Accumulator; void setup() { // put your setup code here, to run once: // int result = myFunction(2, 3); pinMode(GPIO_NUM, OUTPUT); Numerator = 5; Denominator = 7; Accumulator = 0; } void loop() { // Bit band using digitalWrite() => 1.29 Mhz // digitalWrite(GPIO_NUM, HIGH); // digitalWrite(GPIO_NUM, LOW); // Using GPIO.out_w1ts/c => 6.16 MHz // GPIO.out_w1ts = (1 << GPIO_NUM); // Set High // GPIO.out_w1tc = (1 << GPIO_NUM); // Set Low // Dynamic electronic gear // Approximately 4 MHz in free-running mode - however waveform is not square // Adding delayMicroseconds(1) to On & Off phases did generate a square wave, // but dropped the speed down to 200 kHz with inconsistent timing // Use _NOP() x 16 provides sufficient delay to see a true square wave, 2.67 MHz Accumulator += Numerator; if (Accumulator >= Denominator) { GPIO.out_w1ts = (1 << GPIO_NUM); // Set High Accumulator -= Denominator; // This will be part on the ON pulse delay } _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); GPIO.out_w1tc = (1 << GPIO_NUM); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); _NOP(); }

 

[zombieengineer]

Progressed a little further this evening - Now got the ESP32 externally clocked driving the electronic gear algorithm (including code for reversal of direction). I was able to drive this up to 1.1 MHz before steps started merging at 1.2 MHz.



Investigated the dual core option and Core 0 is typically reserved for WiFi / Bluetooth functionality (currently not used) and the main program runs on Core 1. I think I will give the "2nd core" option a miss at this point.

I shifted the electronic gear algorithm to an interrupt routine that is called on a change-of-state of the clock input (Z Axis Step) and was able to get a reliable response up to 170 kHz before steps starts to merge (an indication that a rising/falling edge was missed). One challenge I encountered in the previous project is serial communication could impact GPIO interrupt process (or was it the other way around), this was definitely an issue with the Arduino Nano but I could see no interference when constantly printing "Hello World!" to the serial port on the ESP32.

Although the Arduino Nano was capable of reaching 250 kHz, this was only achieved by pre-calculating the step pulses while the ESP32 is performing the calculations dynamically. This has a huge advantage as some threads (19 TPI) will require 254 bytes of storage to hold the sequence.

Enough of this "Paralysis by Analysis" - shortly it will be time to take this from the test bench and connect up a mill. If I can get the motion synchronised then in theory I should be able to tap using the MPG Pendant (select Z and spin the dial).

 

[zombieengineer]

Early last week I received from an AliExpress vendor a set of "Differential Output Driver" chips similar to the ones used by MASSO for the axis outputs. It appears that these are "new old stock" which were manufactured prior to 2018 by AMD (yes - same company as the CPU maker).



I was initially puzzled by the AMD logo and an internet search led me to Rochester Electronics, which could be described as the "retirement home (manufacturer) of legacy integrated circuits". When a chip manufacturer decides that a particular design is no longer worth producing they will sell the remaining inventory, chip masks to Rochester Electronics who will then continue distributing the remaining stock and sometimes do a production run using the chip masks to refresh their inventory.

Rochester Electronics

The world’s largest continuous source of semiconductors

www.rocelec.com

Having AMD branded chips in their inventory indicates that AMD did manufacture these chips, and therefore these are likely to be unused legacy items (aka "new old stock").

I was previously aware of Rochester Electronics as they had taken over the inventory / production of the old 68040 processor (used in industrial control hardware that is now 30 years old). Due to the storage requirements for maintaining an inventory of parts that sit on their shelf for years, Rochester Electronics charges a premium for their parts. In the case of the 68040 processor the price for a single CPU jumped from $150 to $300 overnight.

 

[zombieengineer]

One of the challenges with the Delta B2 servo motor is that the digital inputs are RUN + REV, while MASSO has separate FWD & REV outputs.

For this prototype I need to "protect against stupidity", specifically when the spindle FWD / REV outputs are active when rigid tapping is active. Depending on the operation I could have a drill trying to be a tap (turns very slowly and will snap the drill) or a tap trying to be a drill. It is better to stop the program with a spindle fault than let the program run and destroy either tooling or work. It is assumed that the MASSO controller will not turn both FWD and REV spindle outputs on simultaneously when the spindle signals are configured for Analog Mode.

The logic for converting FWD/REV to ON+REV

• Servo ON = MASSO-FWD or MASSO-REV or MASSO-Rigid-Tap
• Servo REV = MASSO-REV

The logic to
Spindle Alarm = Servo-ALARM or [ MASSO-Rigid-Tap and (MASSO-FWD or MASSO-REV) ]

The following is the circuit diagram I came up with:



The Servo-SON / 4.7k is the servo driver digital input connection for SON
The Servo-REV / 4.7k is the servo driver digital input connection for REV
The Servo-ALRM is the servo driver digital output connection for ARLM signal (over current, etc)

• D1 to D4 are signal diodes used to form simple OR gates.
  • D1 and D2 form the "MASSO-FWD or MASSO-REV"
  • D3 and D4 form the "(MASSO-FWD or MASSO-REV) or MASSO-Rigid-Tap"
• R1 to R4 are 22k resistors
  • Value chosen to ensure T1-T4 turn off in about 1 microsecond
• T1 to T4 are 2N7000 MOSFET transistors
  • T3 and T4 form a simple AND gate, specifically "(MASSO-FWD or MASSO-REV) and (MASSO-Rigid-Tap)"
• Pull-up resistor would be 6.8k (approximately)
• The two Fault LEDs are 5mm Red LEDs used to differentiate between "stupidity" (Drill/Mill & Tap simultaneously) or "hardware failure" (genuine servo driver error).

 

[Robwhi]

Very interesting project please keep us updated as you have been
I can many see other uses
Thank you

 

[zombieengineer]

@Robwhi - thank you for your encouragement.

---

I attempted to convert the design from the circuit design into a prototype using a "1/4 Breadboard prototype board" and struggled to make the circuit connections. Specifically there are a number of circuit nodes with a high number of connections, the input gate of T4 connects together 5 different components. Breadboards have connection rows with 5 holes but practically you can only use about 3 due to space limitations.

Yesterday evening I realised that my servo drive digital inputs have been setup for positive voltage trigger, while the 2N7000 MOSFETs are low side switching devices (the device conducts when the gate is 2.1V higher than the source pin which is normally connected to 0V). This will mean that some adjustments to support opto-isolators will need to be made, this introduces a number of different issues that need to be considered (number of board connections, switching speed of opto-isolators, required output current switching [3 to 5 mA for the Delta ASDA B2 servo driver]).

So it looks like I will be designing a custom board (costs about USD$25 delivered to use one of the Chinese online PCB manufacturers).

 

[zombieengineer]

This will mean that some adjustments to support opto-isolators will need to be made, this introduces a number of different issues that need to be considered (number of board connections, switching speed of opto-isolators, required output current switching [3 to 5 mA for the Delta ASDA B2 servo driver]).

After experimenting with a circuit simulator I was "enlightened" on how to achieve high speed performance with optocouplers (Yes - bad pun). The root cause is the parasitic capacitance associated with the photo-diode on the output side. Some optocouplers such as the 4N25 have an extra pin which is connected to the base of the output transistor, the photo-diode is effectively connected to the base-collector pins of the output transistor, thus allows direct access to the internal photo-diode.

The trick to making the parasitic capacitance disappear is to maintain a constant voltage across the photo-diode. If the voltage across the parasitic capacitance is constant then any current associated with the capacitance becomes zero. The voltage drop between the base-emitter of a transistor (for the electronic circuit diagram illiterate - the voltage drop across the "arrow head" in the transistor symbol) is effectively a constant 0.65V. Therefore there is effectively a constant 22.7V across the base-collector pins of the optocoupler output transistor.

The following circuit diagram contains both PNP and NPN output. R4 and R8 represent the servo digital inputs, either one could be removed and left open circuit and the other output will function without problems.

When used in the classic circuit (see below) I found that the maximum speed is somewhere between 10 to 20 kHz, with the output voltage looking like a saw tooth (not very square wave). When using the 4N25 purely as a photo-diode (above circuit diagram) I was able to reach 190 kHz (output fed back to the input using a Schmitt-Trigger logic inverter).


So now I can have a high speed optocoupler with both NPN and PNP outputs with only with the addition of two more components (per output). However I do need to bring into the circuit the 0V & +24V from the servo drive, this is required to provide the constant voltage across the photo-diode.

---

There are very high speed digital output optocouplers with push-pull outputs. These are somewhat exotic (read "expensive") and most are only limited to a 5V supply voltage. The Delta ASDA B2 digital inputs have a built-in 4.7K resistor which requires >15V to trigger.

The only digital output optocoupler rated for >24V is the TLP250H, which is recommended for use up to 250 kHz. The problem with this optocoupler is the outputs are only rated for 3 mA which is right on the limit of the Delta ASDA B2 servo driver digital inputs threshold. With the modified 4N25 I was getting 6.8 mA as the maximum output current (with 24V the 4.7K internal resistor limits the current to 4.9 mA).

 

[zombieengineer]

With Autodesk retiring Eagle CAD in June in favour of Fusion360 I attempted to design the prototype board in Fusion360. The interface was slower than I expected, specifically on the virtual machine I do CAD work it was starting to become unusable.

I decided to explore other alternatives and decided to use KiCad as it was the most recommended free alternative. There was still a learning curve, mostly with the key combos for common operations (duplication, move, wire, etc). All the components with the exception of the ESP32 board was built-in, even including the ESP32-Devkit footprint was straight forward (I had more problems with EagleCAD and terminal blocks).

The bulk of the components is to deal with switching the servo mode between Speed & Position control, if this was handled by the G3 controller it could be done at a software level with sufficient reliability that a hardware interlock would be not be necessary.

A pair of BC547 transistors were added to board to buffer the TTL signals from the G3 controller. The differential driver chip requires the logic output to sink about 0.3 mA @ 0.4V, this equates to a pull-down resistor of 1.2k or smaller. Based on the characteristics of the G3 controller output this would be right on the limit of what the output could drive (the G3 TTL output terminal voltage would drop to about 3V due to the pull-down resistor). By using a transistor the signal output will be capable of driving 10 TTL inputs, at the cost of inverting the signal. The signal inversion can be handled by a coding change in the ESP32 code.

 

[safeairone]

I decided to explore other alternatives and decided to use KiCad as it was the most recommended free alternative. There was still a learning curve, mostly with the key combos for common operations (duplication, move, wire, etc). All the components with the exception of the ESP32 board was built-in, even including the ESP32-Devkit footprint was straight forward

Not even 3 days ago I made a custom ESP32-C6 module symbol in KiCad along with an MPM3510A Buck Converter symbol and footprint. KiCad's component library IS otherwise pretty extensive though--certainly a lot more robust than Fusion Electronics, from what I saw in the brief FE use or two I have under my belt.

 

[zombieengineer]

Not even 3 days ago I made a custom ESP32-C6 module symbol in KiCad along with an MPM3510A Buck Converter symbol and footprint. KiCad's component library IS otherwise pretty extensive though--certainly a lot more robust than Fusion Electronics, from what I saw in the brief FE use or two I have under my belt.

The following is the link to the ESP32 library that I used, scroll down until you see "Download here the latest library!" and then follow the instructions:

GitHub - espressif/kicad-libraries: KiCad libraries for Espressif SoCs, modules, and DevKits.

KiCad libraries for Espressif SoCs, modules, and DevKits. - espressif/kicad-libraries

github.com

---

EDIT - Just did a quick sanity check of the spacing of the head pin rows for the ESP32 DevKitC board and found the AliExpress "clones" have the rows 0.9" apart while the official Espressif DevKitC board has the pins spaced 1.0" apart. Five minutes in the foot pad editor to create a narrow variant and then reassign the foot pad and update the PCB traces.

The board is now off with Pcbway so I should have it back by next weekend (which is a long weekend for those of us in Aus / NZ - Lest We Forget).

 

[zombieengineer]

A month later...

Previous boards had issues due to choosing a solder pad arrangement which is not hand solderable. Sent off for another batch of boards which should resolve the issue.

Day job had a couple of crisis tasks land on my desk which has not helped (the kind where "lack of planning on someone else results in crisis for a lot of other people").