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
Despite the extensive work we had done on the roof recently, we saw some water ingress during some recent rainfall. It wasn't exactly biblical downpour territory, so what could have been the issue?
This is what was done:
Refit various loose slates.
Repair the lead lining on one of the valleys.
Replace the chimney pots, saddle stone and repoint the stack.
Replace all gutters and downpipes.
Fit new facias - treated wooden boards and black uPVC facias.
Repoint and seal the battlements (the tops of the bay windows).
Reroof the small bay roof at the office French door, including reflashing.
Strip all slates, battens and felt on the workshop roof, lay in additional joists (to give us reasonably "flat" surfaces on the 2 sloped roofs, compared to the current moonscape feature, and cure the minor leaks around some of the skylights.
Refit new felt, battens and slates. Reuse salvaged slates on the neighbour's side where possible.
Reflash where the roof meets the wall of the house.
Fit new facias, gutters and downpipes on the workshop.
This required covering the entire workshop with scaffolding and shuttering to make it weatherproof while the work is ongoing. And scaffolding the main house when tackling the facias and chimney.
Here's the point of ingress. I've never seen this before, so what could have caused it? Seems unlikely to be a result of the work we had done:
Tissue provides a useful witness, showing where the water was landing.
Why did it come in only on this occasion? It only happened on that day (late morning, 11am - noon on 24th March) and hasn't happened since.
Was the prevailing wind coming from an unusual direction?
Was there some sort of blockage in the drains?
Did something get damaged during the recent work?
There's a website called Weather Spark historical data that logs local weather data hour by hour and is easily searchable. We are about a mile or so from the nearest weather station which is at Blackpool Airport, so we are sort of in luck.
Generally, the prevailing wind at our home is Westerly (from the West, coming off the Irish Sea), although the airport data doesn't seem to reflect that quite as much as I'd expect. I think it's fair to say that the wind had a bit of a Southerly direction on that day.
Note that it hadn't rained for quite a few days before this incident:
So, the best I can conclude is that there was a combination of driving rain and a Southerly component to the wind.
The roofers returned (14th April)and inspected the brickwork above the windows and just below the parapets. The problem seems fairly clear - missing pointing on the facing brickwork. Any water running down the wall is liable to seep into the cracks. Once in there, the only way for it to drain is into the interior. You can see why it would tend to happen under limited circumstances.
The cure seems to be reasonably straightforward - rake out and repoint the flaky pointing.
So - Weather Spark is a pretty handy resource that is work knowing about!
This is a bit of a step for me, having not done any half serious coding for may years. Given the atrophied state of my aged brain, this won't be easy. However, Claude Code has come to the rescue....
To install this collection you need to:
Install Visual Studio Code, aka VSC (already present, as I've been using this for a variety of applications, such as Javascript for post processor modification, LinuxCNC HAL file development, CNC file editing etc).
Install Espressif's ESP-IDF, which is their IDE for development of code for their ESP micrcontroller family.
Install the ESP-IDF extension for VSC. On the face of it, this should be possible (easy?) from within VSC but I tried and failed a few times. Apparently this is not unusual (being a MS product and all), so installing IDF first seems to be the workaround.
Also, ideally install Microsoft's C/C++ development tools, debugger etc extensions for VSC (install from within VSC).
Then, set them up and get them working (arguably shouldn't be a big task but....). I used the "Hello world" example as the simplest possible instance for testing.
And of course, you need to install Claude Code from Anthropic. If you want Claude to create code for you, you will need the Individual / Pro subscription option which costs £15/mo. It's cancellable at any time.
And of course, you now need to be using full-blown C, rather than the higher level, simplified C++ that Arduino is based on. But that's where Claude Code (CC) comes in.
Copying the hello_world example and renaming / resaving it is the cowardly way to get started with VSC/IDF once it's actually up and running. Then you can get Claude busy coding for you:
The little symbols on the taskbar at the bottom allow you to configure the ESP-IDF for your specific ESP32 board (ESP32-S3 in my case), select the COM port, compile, build and flash the code and start the output monitor.
I'd equate the competence of Claude with that of a fairy enthusiastic and excitable but far from infallible senior software engineer - very much like your archetypal American (Microsoft?) cliche.
I find I have to get Claude to thrown the code at the wall a few times before it will stick. But having said that, to extend that metaphor, I'd struggle even to come up with anything to throw in the first place.
What about that test jig you promised, Fatty?
Well, in order to test out the software, I need a physical setup that will allow the Bojke laser distance sensor and the load cell / HX711 to send data simultaneously to the ESP32. Trying to do this by hand merely results in the graph producing horizontal or vertical lines (if twiddling one or other of the sensors) or just a load of random bollocks if I twiddle them at the same time.
What I need is a spring element that generates both a force at the load cell and a displacement at the distance sensor. Ideally I'd also be able to generate some degree of hysteresis (lost motion) but that might be a step for later. To get up and running, I've created the following assembly:
Forgive the auto-generated colours - they allow you to see the different elements within the assembly. It's possible the section view will add some clarity:
It's an odd looking thing but it has to accommodate several elements:
the awkwardly shaped load cell (yellow, bottom)
the laser sensor (shell body at the top right).
the spring element (which is actually a 10cm steel ruler)
a sliding block that allows physical limitation of the movement of the spring.
This concept doesn't actually provide hysteresis so much as a 2-stage spring stiffness factor, but it's sort of close enough for now. I can adjust the position of the block along the spring and also limit the vertical movement of the block before it. There are 3 grub screws in the block. One locks it in position along the spring, while the other 2 provide adjustable limits on the vertical displacement of the block. Thereafter, with any further movement of the end of the spring, the effective spring rate is increased.
And indeed, here it is, hot off the 3D printer:
Operation is simple and crude:
Start the web server by powering up the ESP32 and opening a browser that points to the hard coded IP address.
The load cell is tared at the initial setting and the displacement measurement is zeroed at its rest position.
Start the graphing function (clear the screen first, if necessary) and press on the end of the spring. To characterise the opposite direction, lift the end of the spring.
Stop the graphing function, to prevent further readings.
Here's the output of the first iteration of my stiffness gauge code, which generates a web page with the acquired data:
That works. Next steps:
Linear regression on loading and unloading curves separately for accurate stiffness calculation
Automatic reversal detection to split the two curves
Backlash calculation from the hysteresis gap
It's not intended to be some finely honed device at this stage. But I'm exploring how useful (competent) Claude Code is as much as anything. But that will do for the moment......
Before completely giving up on the Arduino IDE, I got one of the Saleae clone logic analysers. These use an Altera Cyclone FPGA to capture up to 16 channels of digital inputs, then send the data to a Cypress FX2 microcontroller and thence over USB to your PC. From there, there's some rather powerful open source software for processing, displaying and decoding the data. Many different protocols are supported, not least Modbus of course.
Here's what you get on a scope. Very interesting - but you can't tell what is and isn't being sent over the bus. For instance, is it missing any critical bits? Does the CRC check agree. What are we looking at?
You can watch the bus using a tool like qModMaster or Hercules but they won't tell you much if the message is corrupted or missing.
This is where these cheap logic analaysers come in. Mine's from Kingst and https://qdkingst.com/en
Last time I used the ESP32-S3-POE-ETH-8DI-8DO module, it was happy to talk to the Bojke laser sensor. But can I get the ESP32-S3 Mini to talk to it? Can I f*ck.
Claude Code got its knickers in a good old twist trying to figure it out but finally I lost the will to live.
And here's the proof that when I used a USB-RS485 dongle to sniff the traffic, it was working fine:
...using these port settings:
So there's nothing wrong with the Bojke sensor. The Stupid Fat Bloke hasn't been messing about with it behind my back and blown it up.
To get up to speed with Modbus, here's a handy little intro video:
I was starting to get the feeling there was something going on here that nobody told me about. But with some digging, I found this vid discussing why Modbus doesn't work with ESP32:
Bottom line is, Arduino is a sort of Noddy / Newbie IDE for developing code to program the Arduino family and as such it is a fairly high level, cut down version of C++, where many of the functions are actually hidden from the user, to keep life "simple"(!!). Furthermore, although the ESP32 has a lot of support within the Arduino IDE, it's pushing the capabilities of some of the functions that were never intended to be used beyond the actual Arduino family. One of those might be the support for implementing RS485.
Why does the ESP32Arduinocore struggle with RS485 software flow control? 🧐 I recently ran a series of RS485 communication tests using the MAX485 module. Most configurations worked exactly as expected—until I hit a specific wall. I successfully tested: 🔹 STM32 on both CubeIDE and Arduino (Soft Flow Control). 🔹 ESP32 usingEspressif SystemsESP-IDF (Soft Flow Control). 🔹 ESP32 using Arduino (Hardware Flow Control). The catch? When trying to implement Software Flow Control on the ESP32 using the Arduino framework, the communication failed. Since it works fine on ESP-IDF, I suspect it’s an overhead or timing issue within the Arduino core implementation for the ESP32, specifically regarding when the DE/RE pins are toggled relative to the UART buffer. Has anyone patched this or found a workaround? Let’s discuss in the comments!
You had me confused there for some time because RS485 has no notion of either hardware or software flow control like RS232 does, but I infer that you are reffering to the RS485 control of direction . A software command to assert the transmitter enable gpio pin manually works . It is possible to assert the control line before starting a transmission , and negating it after transamission . I myself have done that often . However , the problem almost always is the timing of the negation. It is not good enough to negate the TE/RE control line when the transmit buffers and FIFO becomes empty , as the last byte are still in the transmit shift register being shifted out , and a premature negation of the TE/RE will cause lost of transmitted data . To overcome this , you will have to spin at the end of transmission waiting for the transmit shift register to also become empty , and then negate the RE/TE line. You can use use uart_wait_tx_done(.........) function to block until all bits have been shifted.
So using the Arduino IDE to program an ESP32 to use RS485 may be a bit of an oxymoron - and nobody's going to act surprised or run to help you if you run into problems. The grownups will be using "proper" IDEs such as the dedicated ESP-IDF that Espressif have developed specifically to ..... program the ESP32 family. Oh well, time to "put my big boy pants on" and move on from this time consuming fiasco....
Anton Reinhardt • 3rd+