Retrofitting 1983 Shizuoka AN-SB CNC milling machine, Bridgeport mill, Colchester Bantam lathe and 1982 Tree UP-1000 CNC lathe with modern controls - and other workshop stuff
Ooof. I have this WW2 clock from a Spitfire that I acquired back in the late 70s. Looks in pretty good nick for its age and also seems to be in reasonable semi-running order, as in it almost keeps ticking when you set it off. I guess it needs a clean and some watch oil.
It's marked "AM" on the back, which stands for "Air Ministry".
The movement is Swiss but the watch was manufactured by "Smith and Sons (MA) Ltd" in London. The date is 11th November, 1938, which ties in.
That spring and lever allow the time to be set by rotating the bezel, rather than wind it up.
That looks like an adjustor for the timekeeping, possibly missing a nub? The curved thing connects the external button to the sprung lever which allows time setting. Once released, the bezel defaults to winding it up. This is an "8 day" clock.
Anyway, what about those suspicious looking "luminous" hands? Out with the Radiacode radiation detector.
Hmm. Should I be worried? I'm seeing perhaps 6mR/h, which is about 60uS/h. Sounds as if I shouldn't crush up the paint and put it on my cornflakes. However, once it's a few feet away, the count rate falls right off.
I need to get some watch oil and lube it up a bit. It almost works but stops ticking after a few seconds. I guess 90 year old oil possibly isn't quite as effective as it was when it left the factory.
Well that was a bit of fun. Finally I have something to wake up the Radiacode with.
To get this little generic 128 x 32 pixel OLED display working with the ESP32C3 Dev board, need to load the correct library and also connect up the clock and data pins on the display to the right pins on the ESP32C3.
Good little video showing how to do this by DroneBot Workshop:
There's an example (demo) sketch in the std library at Files > Manage libraries... > Examples from Custom Libraries (right near the bottom) > Adafruit SSD1306 > ssd1306_128x32_i2c:
/************************************************************************** This is an example for our Monochrome OLEDs based on SSD1306 drivers Pick one up today in the adafruit shop! ------> http://www.adafruit.com/category/63_98 This example is for a 128x32 pixel display using I2C to communicate 3 pins are required to interface (two I2C and one reset). Adafruit invests time and resources providing this open source code, please support Adafruit and open-source hardware by purchasing products from Adafruit! Written by Limor Fried/Ladyada for Adafruit Industries, with contributions from the open source community. BSD license, check license.txt for more information All text above, and the splash screen below must be included in any redistribution. **************************************************************************/ // #include <SPI.h> probably not needed #include <Wire.h> #include <Adafruit_GFX.h> #include <Adafruit_SSD1306.h> #define SCREEN_WIDTH 128 // OLED display width, in pixels #define SCREEN_HEIGHT 32 // OLED display height, in pixels // Declaration for an SSD1306 display connected to I2C (SDA, SCL pins) // The pins for I2C are defined by the Wire-library. // On an arduino UNO: A4(SDA), A5(SCL) // On an arduino MEGA 2560: 20(SDA), 21(SCL) // On an arduino LEONARDO: 2(SDA), 3(SCL), ... #define OLED_RESET -1 // Reset pin # (or -1 if sharing Arduino reset pin) #define SCREEN_ADDRESS 0x3C ///< See datasheet for Address; 0x3D for 128x64, 0x3C for 128x32 Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET); #define NUMFLAKES 10 // Number of snowflakes in the animation example #define LOGO_HEIGHT 16 #define LOGO_WIDTH 16 static const unsigned char PROGMEM logo_bmp[] = { 0b00000000, 0b11000000, 0b00000001, 0b11000000, 0b00000001, 0b11000000, 0b00000011, 0b11100000, 0b11110011, 0b11100000, 0b11111110, 0b11111000, 0b01111110, 0b11111111, 0b00110011, 0b10011111, 0b00011111, 0b11111100, 0b00001101, 0b01110000, 0b00011011, 0b10100000, 0b00111111, 0b11100000, 0b00111111, 0b11110000, 0b01111100, 0b11110000, 0b01110000, 0b01110000, 0b00000000, 0b00110000 }; void setup() { Serial.begin(9600); // SSD1306_SWITCHCAPVCC = generate display voltage from 3.3V internally if(!display.begin(SSD1306_SWITCHCAPVCC, SCREEN_ADDRESS)) { Serial.println(F("SSD1306 allocation failed")); for(;;); // Don't proceed, loop forever } // Show initial display buffer contents on the screen -- // the library initializes this with an Adafruit splash screen. display.display(); delay(2000); // Pause for 2 seconds // Clear the buffer display.clearDisplay(); // Draw a single pixel in white display.drawPixel(10, 10, SSD1306_WHITE); // Show the display buffer on the screen. You MUST call display() after // drawing commands to make them visible on screen! display.display(); delay(2000); // display.display() is NOT necessary after every single drawing command, // unless that's what you want...rather, you can batch up a bunch of // drawing operations and then update the screen all at once by calling // display.display(). These examples demonstrate both approaches... testdrawline(); // Draw many lines testdrawrect(); // Draw rectangles (outlines) testfillrect(); // Draw rectangles (filled) testdrawcircle(); // Draw circles (outlines) testfillcircle(); // Draw circles (filled) testdrawroundrect(); // Draw rounded rectangles (outlines) testfillroundrect(); // Draw rounded rectangles (filled) testdrawtriangle(); // Draw triangles (outlines) testfilltriangle(); // Draw triangles (filled) testdrawchar(); // Draw characters of the default font testdrawstyles(); // Draw 'stylized' characters testscrolltext(); // Draw scrolling text testdrawbitmap(); // Draw a small bitmap image // Invert and restore display, pausing in-between display.invertDisplay(true); delay(1000); display.invertDisplay(false); delay(1000); testanimate(logo_bmp, LOGO_WIDTH, LOGO_HEIGHT); // Animate bitmaps } void loop() { } void testdrawline() { int16_t i; display.clearDisplay(); // Clear display buffer for(i=0; i<display.width(); i+=4) { display.drawLine(0, 0, i, display.height()-1, SSD1306_WHITE); display.display(); // Update screen with each newly-drawn line delay(1); } for(i=0; i<display.height(); i+=4) { display.drawLine(0, 0, display.width()-1, i, SSD1306_WHITE); display.display(); delay(1); } delay(250); display.clearDisplay(); for(i=0; i<display.width(); i+=4) { display.drawLine(0, display.height()-1, i, 0, SSD1306_WHITE); display.display(); delay(1); } for(i=display.height()-1; i>=0; i-=4) { display.drawLine(0, display.height()-1, display.width()-1, i, SSD1306_WHITE); display.display(); delay(1); } delay(250); display.clearDisplay(); for(i=display.width()-1; i>=0; i-=4) { display.drawLine(display.width()-1, display.height()-1, i, 0, SSD1306_WHITE); display.display(); delay(1); } for(i=display.height()-1; i>=0; i-=4) { display.drawLine(display.width()-1, display.height()-1, 0, i, SSD1306_WHITE); display.display(); delay(1); } delay(250); display.clearDisplay(); for(i=0; i<display.height(); i+=4) { display.drawLine(display.width()-1, 0, 0, i, SSD1306_WHITE); display.display(); delay(1); } for(i=0; i<display.width(); i+=4) { display.drawLine(display.width()-1, 0, i, display.height()-1, SSD1306_WHITE); display.display(); delay(1); } delay(2000); // Pause for 2 seconds } void testdrawrect(void) { display.clearDisplay(); for(int16_t i=0; i<display.height()/2; i+=2) { display.drawRect(i, i, display.width()-2*i, display.height()-2*i, SSD1306_WHITE); display.display(); // Update screen with each newly-drawn rectangle delay(1); } delay(2000); } void testfillrect(void) { display.clearDisplay(); for(int16_t i=0; i<display.height()/2; i+=3) { // The INVERSE color is used so rectangles alternate white/black display.fillRect(i, i, display.width()-i*2, display.height()-i*2, SSD1306_INVERSE); display.display(); // Update screen with each newly-drawn rectangle delay(1); } delay(2000); } void testdrawcircle(void) { display.clearDisplay(); for(int16_t i=0; i<max(display.width(),display.height())/2; i+=2) { display.drawCircle(display.width()/2, display.height()/2, i, SSD1306_WHITE); display.display(); delay(1); } delay(2000); } void testfillcircle(void) { display.clearDisplay(); for(int16_t i=max(display.width(),display.height())/2; i>0; i-=3) { // The INVERSE color is used so circles alternate white/black display.fillCircle(display.width() / 2, display.height() / 2, i, SSD1306_INVERSE); display.display(); // Update screen with each newly-drawn circle delay(1); } delay(2000); } void testdrawroundrect(void) { display.clearDisplay(); for(int16_t i=0; i<display.height()/2-2; i+=2) { display.drawRoundRect(i, i, display.width()-2*i, display.height()-2*i, display.height()/4, SSD1306_WHITE); display.display(); delay(1); } delay(2000); } void testfillroundrect(void) { display.clearDisplay(); for(int16_t i=0; i<display.height()/2-2; i+=2) { // The INVERSE color is used so round-rects alternate white/black display.fillRoundRect(i, i, display.width()-2*i, display.height()-2*i, display.height()/4, SSD1306_INVERSE); display.display(); delay(1); } delay(2000); } void testdrawtriangle(void) { display.clearDisplay(); for(int16_t i=0; i<max(display.width(),display.height())/2; i+=5) { display.drawTriangle( display.width()/2 , display.height()/2-i, display.width()/2-i, display.height()/2+i, display.width()/2+i, display.height()/2+i, SSD1306_WHITE); display.display(); delay(1); } delay(2000); } void testfilltriangle(void) { display.clearDisplay(); for(int16_t i=max(display.width(),display.height())/2; i>0; i-=5) { // The INVERSE color is used so triangles alternate white/black display.fillTriangle( display.width()/2 , display.height()/2-i, display.width()/2-i, display.height()/2+i, display.width()/2+i, display.height()/2+i, SSD1306_INVERSE); display.display(); delay(1); } delay(2000); } void testdrawchar(void) { display.clearDisplay(); display.setTextSize(1); // Normal 1:1 pixel scale display.setTextColor(SSD1306_WHITE); // Draw white text display.setCursor(0, 0); // Start at top-left corner display.cp437(true); // Use full 256 char 'Code Page 437' font // Not all the characters will fit on the display. This is normal. // Library will draw what it can and the rest will be clipped. for(int16_t i=0; i<256; i++) { if(i == '\n') display.write(' '); else display.write(i); } display.display(); delay(2000); } void testdrawstyles(void) { display.clearDisplay(); display.setTextSize(1); // Normal 1:1 pixel scale display.setTextColor(SSD1306_WHITE); // Draw white text display.setCursor(0,0); // Start at top-left corner display.println(F("Hello, world!")); display.setTextColor(SSD1306_BLACK, SSD1306_WHITE); // Draw 'inverse' text display.println(3.141592); display.setTextSize(2); // Draw 2X-scale text display.setTextColor(SSD1306_WHITE); display.print(F("0x")); display.println(0xDEADBEEF, HEX); display.display(); delay(2000); } void testscrolltext(void) { display.clearDisplay(); display.setTextSize(2); // Draw 2X-scale text display.setTextColor(SSD1306_WHITE); display.setCursor(10, 0); display.println(F("scroll")); display.display(); // Show initial text delay(100); // Scroll in various directions, pausing in-between: display.startscrollright(0x00, 0x0F); delay(2000); display.stopscroll(); delay(1000); display.startscrollleft(0x00, 0x0F); delay(2000); display.stopscroll(); delay(1000); display.startscrolldiagright(0x00, 0x07); delay(2000); display.startscrolldiagleft(0x00, 0x07); delay(2000); display.stopscroll(); delay(1000); } void testdrawbitmap(void) { display.clearDisplay(); display.drawBitmap( (display.width() - LOGO_WIDTH ) / 2, (display.height() - LOGO_HEIGHT) / 2, logo_bmp, LOGO_WIDTH, LOGO_HEIGHT, 1); display.display(); delay(1000); } #define XPOS 0 // Indexes into the 'icons' array in function below #define YPOS 1 #define DELTAY 2 void testanimate(const uint8_t *bitmap, uint8_t w, uint8_t h) { int8_t f, icons[NUMFLAKES][3]; // Initialize 'snowflake' positions for(f=0; f< NUMFLAKES; f++) { icons[f][XPOS] = random(1 - LOGO_WIDTH, display.width()); icons[f][YPOS] = -LOGO_HEIGHT; icons[f][DELTAY] = random(1, 6); Serial.print(F("x: ")); Serial.print(icons[f][XPOS], DEC); Serial.print(F(" y: ")); Serial.print(icons[f][YPOS], DEC); Serial.print(F(" dy: ")); Serial.println(icons[f][DELTAY], DEC); } for(;;) { // Loop forever... display.clearDisplay(); // Clear the display buffer // Draw each snowflake: for(f=0; f< NUMFLAKES; f++) { display.drawBitmap(icons[f][XPOS], icons[f][YPOS], bitmap, w, h, SSD1306_WHITE); } display.display(); // Show the display buffer on the screen delay(200); // Pause for 1/10 second // Then update coordinates of each flake... for(f=0; f< NUMFLAKES; f++) { icons[f][YPOS] += icons[f][DELTAY]; // If snowflake is off the bottom of the screen... if (icons[f][YPOS] >= display.height()) { // Reinitialize to a random position, just off the top icons[f][XPOS] = random(1 - LOGO_WIDTH, display.width()); icons[f][YPOS] = -LOGO_HEIGHT; icons[f][DELTAY] = random(1, 6); } } } }
And checking the ESP32C3 pinout for the clock (SCL or SLC?) pin 12 and data (SDA) pin 13, I powered it up and I seem to have a goer. It's upside down of course.
That's a hopeful start. Obvs I don't want all the demo code in my project but I can strip that out and replace it with my setpoint data.
Since last time, I've been buying stuff. This is inevitable I'm afraid but on the upside I think I'm getting some direction finally.
There are some pretty powerful yet tiny microcontrollers around these days - almost too much of a choice at that. However, I'm much more comfortable with the Arduino IDE (aka C++) than Raspbery Pi (Python). I know, I know - you can actually run Arduino on RP and Python on Arduino but it's simpler to stick to one environment.
As for the actual micro itself, the original Arduinos were based on the ATmel ATMEGA family of processors but since then, a range of other micros have been used in the Arduino family, such as the 32 bit RA4M1 series from Renesas (used on the current Uno R4 etc) and the ESP32 family from Espressif. In the meantime, the form factor has shrunk massively (so to speak). So now you can get devices such as the Arduino Nano 32 bit ESP32 C3 Supermini that are little bigger than your thumbnail, yet are much more powerful than the original (and massive) 8 bit Arduino, while also implementing Bluetooth BLE and Wifi.
Here's an original form factor Uno R4 on the right (with a "terminal block shield" breakout board on top), next to an Arduino ESP32 in the "Nano" form factor, alongside an Arduino C3 in the "Supermini" ("half Nano"?) form factor.
The Supermini form factor is pretty small...
...small enough to hide behind your thumb
That thing is just 18mm x 22.5mm
Here it is alongside a small 10k pot. Even though the pot is tiny, it's not much smaller then the Arduino itself - and I am planning to use 3 of them.
Here's a Nano / Supermini alongside an Allegro A4988 stepepr motor driver board (the A4988 itself is hiding under the finned heatsink), then 3 pots and a small TFT display.
I can just about imagine the 2 PCBAs and 3 pots being integrated on a long, narrow motherboard with the display sitting on top. That would require a board of ~80mm long (plus some extra for connectors), with a width of ~20mm. With the display sitting on top of the pots, I'd have a height of around 12-13mm. The whole thing would then be housed in a 3D printed enclosure, ideally mounted on the torch head.
Alternatively, I could go for a "more square" footprint, with the pots alongside the PCBAs. That would look something like ~50mm long and ~30mm wide. Given that this assembly would ideally be mountable (and demountable) on to the torch head, a long, thin form factor might not be ideal.
How about some software?
It's all very well getting all excited about Arduino hardware but at some point, I'm going to have to write some software to make this thing come to life. Last time I decided what functionality it would need:
Variable speed of forward motion
Variable spot welding frequency
Variable duty cycle (regardless of the frequency)*
* I may decide later that frequency and the on time should be set independently. There is no right or wrong and it's not a critical design decision, so this is how I will set out. I can always change that part of the code later.
So I will have 3 analogue inputs (aka potentiometers) and 2 distinct timer circuits. For the timers, it's not a good idea to use the "delay" function as it causes the whole program to pause. Instead, the method is to use the "millis" (milliseconds) or "micros" (microseconds) timers that count up from the time the micro wakes up.
For the motor drive, I need a variable frequency output to drive the STEP input of the A4988 driver. I don't expect to need to drive the motor backwards at any point, so (for now at least) I won't be driving the DIR(ection) input of the A4988. Rather than make my own hookey variable frequency source, there is a convenient library "AccelStepper" that does all the work, so I've used that. Sounds as if the originator is an experienced software engineer - but one that can't be arsed to write a manual for his work. Pity that - but luckily Mr Hackaday has stepped in to do the dirty work with his handy "AccelStepper - The Missing Manual". This was pretty helpful in getting things running.
This works as described. Here's what I've got today. It generates a variable spot welding frequency, variable duty cycle and variable forward speed. Some of the variable names are rather haphazard and need to be rationalised, so there is certainly work still to be done:
#include<Arduino.h>
#include<AccelStepper.h>
// constants to set pin numbers = 13 - use built in LED for test / dev
constint pwmPin = 13; // the number of the green LED pin
constint dutyCycleAnalogIn = A0; // Analog input- PWM duty
constint periodAnalogIn = A1; // Analog input - period (ms)
constint speedAnalogIn = A2; // Analog input - speed (Hz)
constint maxPeriod = 5000; // hard coded max on time
constint dirPin = 4; // pin 4 used for DIR output
constint stepPin = 5; // pin 5 used for STEP output
// Variables will change
int pwmState = HIGH; //ledState for PWM output
int pwmSensorValue = 0; // value read from the pot
int periodSensorValue = 0;
int speedValue = 0;
long plot = 0;
// Define the stepper motor and the pins that is connected to:
AccelStepper stepper1(AccelStepper::DRIVER, stepPin, dirPin); // (Type of driver: with 2 pins, STEP, DIR)
Rather than simply have an add-on ESP32 for wifi and Bluetooth, "the Nano ESP32 features the ESP32-S3 system on a chip (SoC) from Espressif, which is embedded in the NORA-W106 module. The ESP32-S3 has a dual-core microprocessor Xtensa® 32-bit LX7".
The downside of this exciting feature set is evident when you compile even the simplest code. The first attempt took almost 5 minutes, leaving me wondering WTF was wrong with my laptop. It appears that there's nothing much you can do to speed it up - it's something to do with the much larger libraries that come with the SoC. Sod that - I've now ordered the more common or garden version of the Nano, aka Nano Every, which features a more conventional ATmega4809 processor.
I have an Arduino Uno R4 Wifi which also incorporates the ESP32 - but only as a peripheral. The microcontroller is a Renesas RA4M1, which is hopefully closer to the Atmel family and sure enough, it compiles much quicker (~20s, as opposed to ~5 minutes). I'm hopeful (hoping) that the Nano Every is similarly quick to compile for.
Also arrived today, what looks like a Chinese clone of the Pololu A4988 driver:
Program elements:
Timer:
Rather than use delays to implement on and off time, it's far better to run an endless loop and evaluate / toggle outputs against the required on and off times. This is referred to as "blink without delay" in the documentation. The issue with using delay is that it actually causes the program to stop execution until the delay has ended. If you wanted to do anything else during that time, you'd be out of luck. By running tasks in a loop, you can run multiple tasks independently and simultaneously.
This is a common approach, one I seem to recall implementing over 40 years ago when I developed a 16 channel self tuning PID controller for my final year project at uni. That was written in Pascal (!) but to my mind it's actually quite similar to C. In contrast, my old, addled brain struggles with Pascal, which pretty much rules out using a Raspberry Pi.
int sensorPin = A0; // select the input pin for the potentiometer
int ledPin = 13; // select the pin for the LED
int sensorValue = 0; // variable to store the value coming from the sensor
void setup() {
// declare the ledPin as an OUTPUT:
pinMode(ledPin, OUTPUT);
}
void loop() {
// read the value from the sensor:
sensorValue = analogRead(sensorPin);
// turn the ledPin on
digitalWrite(ledPin, HIGH);
// stop the program for <sensorValue> milliseconds:
delay(sensorValue);
// turn the ledPin off:
digitalWrite(ledPin, LOW);
// stop the program for <sensorValue> milliseconds:
delay(sensorValue);
}
I will bugger about with that and implement it as the input(s) to control the speed and duty cycle.
Trigger input:
I'm looking for a high / low switch status rather than an analogue signal. Here's some example code.
void setup() {
//start serial connection
Serial.begin(9600);
//configure pin 2 as an input and enable the internal pull-up resistor
pinMode(2, INPUT_PULLUP);
pinMode(13, OUTPUT);
}
void loop() {
//read the pushbutton value into a variable
int sensorVal = digitalRead(2);
//print out the value of the pushbutton
Serial.println(sensorVal);
// Keep in mind the pull-up means the pushbutton's logic is inverted. It goes
// HIGH when it's open, and LOW when it's pressed. Turn on pin 13 when the
// button's pressed, and off when it's not:
if (sensorVal == HIGH) {
digitalWrite(13, LOW);
} else {
digitalWrite(13, HIGH);
}
}
That's my starting point.
Some quick sums:
Motor drive pulses: With a 25mm dia / 75mm circumference wheel and weld spots 5mm apart, fired once per second, I'd want @15 seconds per rev of the wheel. Ignoring the gear ratio between the motor and wheel and assuming 200 steps per rev, I would need a pulse frequency of ~13 pulses per second. Allowing for some adjustment, that might result in 5-25Hz. If I implement microstepping at x16 (to minimise noise etc), that would translate to 80-400Hz.
Duty cycle: I'm guessing ~1Hz or so hard coded pulse frequency and 10-100% duty cycle to give good control over the pulse duration.
Releasing the trigger shouldn't result in immediately killing the arc. I'd want the pulse to finish ie not to be followed by another.
Similarly, the trigger should initiate a complete pulse, not a fraction of the steady state output.
Being a nosey b4stard, The Stupid Fat Bloke took the smaller one apart and managed to drop the guts on the bench by opening it upside down. There's a load of different gears and spacers that have to be assembled in the correct positions before the lid will go back on, so I had to figure that all out for him.
What's going on now, Fatty?
10 years ago, I made this little powered trolley thingy. Little stepper motor with (high temperature!) O-rings and a small stepper motor.
The Linbin is simply a means of avoiding accidental short circuits and blowing the thing up.
The Schmalzhaus stepper driver is an Allegro A3967 that takes a step/dir signal and drives the motor. The MSP430 is simply being used as a pulse generator. I don't recall why I went this route but certainly there are simpler means of generating pulses and ideally it would be possible to change the frequency (speed) of the drive.
Then there's also this thing:
Inside there's a PP3 9V battery and a brushed DC motor driver.
After 10 years, the battery still has some electrons to spare, although not enough to actually turn the motor.
This DC motor driver seems to be from Canakit. This is a very simple PWM generator with a FET and flywheel diode, driven by a 555 timer. Hardly the height of sophistication.
It simply drives the large wheel (also sporting a high temperature O-ring)
What's the point of all this?
Perhaps this will help.
Yes, it's a motorised head for driving a MIG welding torch. It was originally aimed at helping me to weld exhaust pipes, where consistent welding conditions are critical if you want to avoid blowthroughs.
It was showing some promise when I had to pack it all away (something to do with moving the workshop, house and family back to the UK from Canada). It was showing promise:
And the bits I just acquired are intended to be another attempt at making one of these.
There are a couple of other bits and pieces I bought back then of varying appropriateness, including this thing. The least said the better...
Another escapade with Chinese connectors:
Yes, I'm thinking how I might make a useable version of the above, with a view to integrating it with the MIG welder.
How would I get the welder and the motorised head to operate together? Ideally the motor would come on when the torch trigger is pressed - and would be powered by the welder.
Battery power is all very well but the MIG has a connector on the front for powering the spool gun, so it makes sense to see if I could use that to power any such device. Here's the plug on the spool gun - China's finest:
It looks like this one. It seems to be described as another "aero connector", although I'd be concerned if any aircraft I travelled on sported these things. Either way, here's the socket on the front of the MIG machine:
And here's what's shown in the manual. No voltage specified:
This is what turned up from Amazon. Close - but no cigar. Can you see the problem?
Yes, the welder has female contacts and the Amazon product also has female contacts. Doh.
I bought 2 sets of these male/female connectors, so I can butcher one of them if necessary. Obvs I'd rather not but at £4 each, it wouldn't be the end of the world if I can come out of it with only one surviving connector that mates with the welder.
The central body is a slight rattle fit in the outer body and the rear has a larger diameter than the front, so clearly it's been push fitted in from the back with some form of ramp / latch to retain it.
Sure enough, it's a simple matter to press the central body back out of the outer housing.
I was then able to push the alternative central guts back into the outer body.
Bottom line- yes, it works.
I now have 2 sets of connectors of each polarity. I can swap the remaining pair over if I find I need a second set.
How does the spool gun operate with the MIG welder?
The trigger switch on the spool gun operates a NO switch which energises the welding power to the torch. If the spool gun mode is selected from the front panel, the main feed motor is disabled and instead, the power for the feed motor is diverted to that 4 position connector (pins 1 and 2). The voltage measures as 22Vdc with no load connected. That's pretty much as you might expect.
So if you wanted to power a torch motor (to move the torch along the weld line), you might want to use that front connector - but unfortunately it will only work when the spool gun is being sued ie no use when you are using the main wire feed.
I guess I could modify the main unit so that 22V is fed to the 2 spare pins on the connector - or use a battery. Not what I would consider ideal.
What's the plan then, Fatty?
Looking at the various artefacts and having a play with them, I've concluded the following:
"One wheel drive" on a 4 wheeled bogie isn't a great concept. Unless you apply constant pressure to the one driven wheel, the "cart" version doesn't have any traction.
The "square tube with the big wheel" thingy isn't a serious option, apart from being obviously fragile in its current state. I quite like the idea of a single wheel adjacent to the torch head but to begin with I feel more interested in pursuing the 4 wheeler concept. I might come back to this later.
The 4 wheeled bogie would be greatly improved if both wheels on each side were driven. This could be achieved by fitting a longer o-ring (drive belt) that goes around the motor and both wheels. I might refer to this as the "tracked" concept.
Changing to a "dual shaft" motor (where the output shaft comes out both ends of the motor) would allow both sides to be driven.
Trying to use the tracked concept on an inside corner might be tricky. I could imagine it being possible but TBH, this isn't really the target application, which is more sheet metal and thin pipe.
So, if I implemented this scheme on both sides of the motor, using a dual/double shaft motor, I'd achieve a sort of "all wheel drive" scheme, almost akin to a tracked vehicle. It would also be suited to running around the outside of a pipe.
The o-ring would ideally be rated for a fairly high temperature. Viton (FKM or "fluorinated") is suitable over 200C, whereas the default nitrile isn't much use above 120C or so. FFKM is rated even higher but is much more expensive - I can always get some later if / when I conclude this concept has legs. Silicone rubber would survive high temps but it's far too elastic (soft) to work as a traction element.
This motor is 42x42x34mm ie same size as previous but with dual shafts. At a tenner each plus postage, that doesn't seem like a bad deal, assuming they are a genuine outfit.
How to interface with the welder?
Unlike the old CEA MIG I have just jettisoned, the Arc Captain MIG200 doesn't have a pulsed "stitch" welding mode. It has a "spot welding" mode which energises the arc for a fixed on time after the trigger is pressed.
I'm thinking that I'd probably use an Arduino Nano to drive the Schmalzhaus stepper motor shield (or similar). It could also control the distance between "spots" (aka "dimes" to the Youtube warriors), independent of the speed of the torch. The number of step pulses to the motor and the distance between spots would be ratiometrically fixed - so I'd have one pot for speed and another for spot distance. The welder would be triggered by the Arduino to produce each spot weld.