Below are some notes on the video, easier to copy-paste if needed.

First things first, power it up

After unpacking the board, it’s good to power it up using the USB-C connector. The box can be used as an isolator, so you don’t subject the board to static electricity. You should be able to see activity on the CPU and the eMMC leds and after a few seconds the heartbeat led will start flashing.

At this point there are three options for controlling the board.
1. Connect the Ethernet cable
2. Connect with Wi-Fi to the board as an access point
3. Use a terminal to get access via USB-C.

Using Ethernet

If you have an Ethernet cable and a switch available, this is the easiest option. Connect the cable between the board and the switch. The board is set up to get an IP address via DHCP. The board is also configured with Avahi to give it mDNS/DNS-SD capabilities. That means it should be available as recore.local and using avahi-browse -a, it should show up as an SSH terminal.

Using Wi-Fi

The board can work as an access point or connected to a separate access point. It can be good to check that Wi-Fi is working by connecting to it either from a computer or a phone. Start by connecting a USB Wi-Fi dongle to one of the USB connectors. There should be some activity on the USB led. After running a scan for local access points from a computer or phone, the board should show up as Recore.

Since the board is set up in access point mode, trying to connect to a different access point will drop the connection. Having a good user experience for this is on the list of improvements, but for now we need a separate way to set up Wi-Fi.

In the video I use the USB-C to set up a terminal and run NMTUI. The hotspot/AP is deleted before running a scan to show local APs. I’m not sure why, but I had to exit and restart nmtui after deleting the hotspot in order to get nmtui to run a scan for local APs. You don’t really have to delete the Hotspot AP, it should be enough to just activate a new connection. A hot tips for getting colors in Minicom is to start it with color enabled (-c on):
minicom -o -D /dev/ttyACM0 -c on

The post Getting Started with Recore A8 appeared first on www.iagent.no.

We still have the market leading TMC2209 stepper motor drivers with good heat spread allowing high current to be drawn. The same with the input stage which is able to handle up to 30 A. Clever use of solid state power handling gives the board programmable over current protection which is both fast acting and incorporates over temperature.

The Allwinner A64 is still a great choice as the CPU (or SoC to be exact) since it is plenty powerful for a 3D printer, it has great upstream kernel support for all functionality and it has that integrated AR100 CPU giving us a fully fledged 300 MHz real time capabilities built into the silicon.

Recore A8 comes with Rebuild v1.0.1 pre-installed (the Fluidd version), but the user can choose to switch to MainSail or OctoPrint if they want.

The post Recore A8 is now shipping! appeared first on www.iagent.no.

This blog post will give a written account of what the video shows. TL;DR watch the video.

Recore comes with software pre-installed. For Recore A7 that has been MainSail as the top level software that the user interacts with. some users have requested OctoPrint and Fluidd instead as alternatives, so we offer those user interfaces as well for those who want them. If you want to go from one software to another, it can be a good idea to do a clean install, meaning you wipe the eMMC completely.

Because Recore has eMMC instead of MMC, that process looks a little different from those platforms that use MMC. The solution that has been chosen is to to use a USB drive as an intermediary and run the board from that instead of from the eMMC in order to completely wipe the eMMC and install fresh software. The image that runs on the USB drive is called Reflash and it is a simple webserver that allows you to download new software and flash it on to the board.

The new way to get back to Reflash, once you have made the conversion, will be to physically insert a USB drive with Reflash in one of the USB host ports. During booting, u-boot will scan the ports looking for a suitable image. If one is found, the boot process is continued using the Linux image on the USB drive. Since the the distro on the USB drive is created as an InitRD, there is no danger of ending up with a corrupt filesystem as a result of removing the drive after a flashing operation has finished. As always, all software is open source, so the underlying script for creating Reflash can be looked at for inspiration and profit.

It’s worth noting that in order to start using this new regime, it is necessary to set Recore into FEL-mode. This is done by holding down the FEL-button while pressing the RST-button on the board. It means that you need physical access to the board. It is also necessary to connect the board up to a host computer using a USB-C to A cable. Once you have managed to boot to Reflash v1.0.0 once, you should not need to do this again.

Here is the wiki-page for Reflash v1.0.0. As of this writing, it is still not a stable release, but it should work for most people. Once booted, you have the choice of installing either Refactor v3.2.0 or Rebuild v1.0.0. The recommended choice is then going for Rebuild once that is at a stable version. There should not be any huge changes in the way things are working, most of the differences between Refactor and Rebuild is behind the scenes in the way the images are built.

The post Reflash: A new way to upgrade firmware appeared first on www.iagent.no.

As explained in the video, there are 4 different sensors that can be used with Recore: Thermistor, Thermocouple, PT100 (using an amplifier) and PT1000. Both Revision A5 and A6 can get very accurate measurements, but A6 can use the upstream Klipper implementation for all sensors without any custom calculations. A5 requires the Intelligent-Agent branch of Klipper.

The dry well calibrator (sometimes called a dry block calibrator) is a chunk of highly temperature conducting material, for instance aluminum, that has holes that fit the temperature sensors to be calibrated well. It’s also important to keep the plane in which the sensors reach equal among the sensors, to get the same readings. One possible source of error in this implementation is the depth of the holes. The reference should have a hole of 20 x D, which for the SDL S385 is 6 x 20 = 120 mm, but achieving that with a 2 mm hole (for the thermocouple) was unfeasible, so a depth of 40 mm was chosen instead.

The dry well in the video was constructed from a 55 mm diameter x 300 mm cylinder of 6061 aluminum stock that was purchased on eBay. The heater is a 220 V, 500 W, 10.5 mm heater from Ali Express. The heater is controlled with a solid state relay ED24D3 from Sensata-Crydom (Digi-key Part number CC1825-ND). The PT1000 is a 31500989 from Heraeus Nexensos (Digi-key part number 1759-1044-ND) and the reference temperature sensor is an SDL model S385 from Sensing Devices Ltd. A model for the dry-well was created in FreeCad.

In the video, the reference temperature sensor is calibrated using de-ionized water with with ice cubes made of de-ionized water and boiling de-ionized water. The boiling point of water is determined using a barometric pressure senor from Seeed Studio (Digi-key part number 1597-101020812-ND). The uncertainty of the pressure sensor was given at +/- 8 m. The 1 mA of current is supplied by an HP 3245A and the voltage is measured by an HP 3458A.

The results achieved was within about 1 degree of each other for the 4 different sensors tested. It should be noted that even though temperature measurements seem simple to carry through, it was much work calibrating the reference, measuring the sensors several times, tuning the input values to the sensors and even creating models in SPICE to reverse engineer the effects on the inputs and model them in code for Klipper.

For those with a Recore A5, I will be updating the Intelligent Agent Klipper branch with the new input stage model, so a software update is needed. The new way of doing it is to disable the offset which makes the offset become a pull-down which is easy to model in code (in contrast with a pull-up to a voltage which is lower than the maximum input voltage).

The post Recore calibration results appeared first on www.iagent.no.

• External r_sense resistors for the TMC2209s.
• Better ESD protection for CE compliance
• Single voltage domain for pull-ups, offsets and ADC.
• Two 5V PWM outputs for easily adding BLtouch or servos.
• Better testability and calibration (pull-up resistors are measured with HP3458A)
• High speed capability on USB device port (A5 had full speed)
• Less noisy thermocouple inputs.

Recore is released as open schematic, so for those interested, the schematic is available in the Repository: https://github.com/intelligent-agent/Recore/tree/master/Schematics

Even more changes have happened on the software side. Refactor is now up to version 3.0.2, with 3.0.3 on the way. A quick rundown of the changes are:

• Separate boot partition for better stability
• A Separate tab in OctoPrint for installing Refactor to eMMC.
• Automatic flashing of the MCU on first boot.

From v3.0.1 there were also a few changes:

• Syncing Klipper with upstream
• Github actions for building Refactor Recore and Replicape
• Support for TMC2209
• Better handling of restart for Recore.
• Replicape uses latest official BeagleBoard image as staring point

The post Recore rev A6 is shipping appeared first on www.iagent.no.

Functional testing

The testing procedure for Recore is done by the board itself. This is convenient because it makes it easy to access the data available on the board, such as values that must be collected from various sensors. These are:

• Voltage on the input
• Current used by the board
• Board temperature
• 4 thermistor/thermocouple inputs
• Cold junction temperature

All the analog values are gathered by the microcontroller on the board and sent to the SoC via UART. In addition to this, all inputs and outputs must be tested. These are:

• 4 High power outputs
• 4 Fan outputs
• 6 Endstop inputs
• 4 USB
• 6 Stepper motors
• 1 HDMI output
• 1 Ethernet
• 23 Voltages

The stepper motors and endstops are tested together, simply letting the motor run until the endstops are hit. The HDMI is tested by sending a known image to a Manga Screen with a USB webcam pointed at it and using ImageMagick to check for similarity. Ethernet speed is tested using Iperf. Mosfet outputs are tested by checking that the on and off values are correct using a separate microcontroller on the testing jig.

Calibration

It’s great to have good equipment for running the tests, but where the equipment is really needed is during calibration of the gain and offset for the programmable instrumentation amplifier. The thermistor/thermocouple inputs can be programmed to have either a 1 time gain or a 101 times gain. This is done by either pulling a resistor low using a GPIO pin or by setting it to high Z which will eliminate it from the equation. There is also a programmable pull-up that can be used to create a voltage divider for a thermistor.

With this setup, the amplification at various voltage levels can be measured. From this, using linear regression, the gain and offset can be calculated as G = ΔVo/ΔVi. The offset is simply the output value measured at 0 volt input. The offset value can be measured by the end user by shorting the input to ground, disabling the pull-up and setting the gain to 101.

Details on accuracy of thermocouple

In the video, I mention that the tolerance of the resistors used are ±1 %, but a good thermocouple can have a 1 degree accuracy across the temperature range. These are values that do not easily compare, so allow me to clarify. A type S thermocouple is actually not that much in use any more, but regardless, the tolerance is very good. ± 1 ºC from 0 to 1100, which is < ± 0.1 %. Below is the IEC 584 chart used as reference.

Thermal experiment

The video ends with an experiment comparing three thermocouples. Unfortunately, I don’t yet have a proper thermometer that I trust, so the results must be taken with a grain of salt. Also, the test was conducted with a fast temperature rise followed by a gradual cool down. This is not ideal since the temperature in the aluminum block needs time to reach equilibrium. A better test would be to use a dry-well and allow the well to settle at different levels. Still, during the cool-down, the temperatures actually matched pretty well for a large range of values.

The post How Recore is Tested and Calibrated appeared first on www.iagent.no.

But this blog post and accompanying video will be centered around porting Klipper to be compatible with the new Recore. Here is the video, the rest of this post we give some details that did not make it into the video.

Here is that block diagram of Allwinner A64 again for reference.

Normally a Single Board Computer (SBC) that runs Linux is not suited for real time operations. That is why a microcontroller is needed which is why you end up with a combination of regular 3D-printer control board and a Rasberry Pi. There are exceptions, for instance the BeagleBone family has a separate (Programmable Realtime Unit) PRU which solves this elegantly.

In Recore I wanted to get rid of that separate microcontroller and find a solution similar to what the PRUs on the BeagleBone is doing. The solution is to use the AR100 which is a bit of a quirky “microprocessor” embedded on the Allwinner A64. But it’s fast! It can run at 300 MHz. Finding a similar microcontroller as a separate device would increase the final price quite a bit without really adding anything.

As mentioned in the video, in order to use the AR100 for real time operations, and to make it work with Klipper, there were three problems that needed to be solved.

Toggle Pins Fast

If you try to toggle pins from Linux, you will be disappointed. It is very slow and unpredictable since the pin toggling events are handled by the kernel and the program is running in user space. Also, the event be handled only when the kernel sees fit which can take a while. But even if you set aside a separate core out of those 4 cores in the A64, you would still be hunted by some amount of unpredictability since the toggling even has to be propagated on the same AHB as most other media on the SoC.

By offloading those events to the AR100, we can get very good speed and predictability. The more we can stay away from the AHB dedicated to the AR100, the less jitter we experience on the toggling of those pins. More jitter will cause steps on the stepper motors to appear uneven and can in turn cause wobbling on the finish of printed objects. I’ve not done extensive testing on this, but it would be a very interesting experiment.

The experiment shown in the video shows the difference between toggling pins that are in one of the GPIO banks and comparing to pins that are in the R_GPIO bank. If you look at the chart above, the “path” taken for the AR100 to toggle the pins in the GPIO bank is a bit more crooked and running through two shared buses, one of which potentially has a lot of traffic.

Communication Channel

In an effort to offload as much traffic as possible on the AHB, I chose a somewhat unconventional way to set up communication between the main Klipper program running on Linux and the real time bit running on the AR100. The conventional way might be to use a shared memory area to “send” commands, since both CPUs are on the same die. Instead, I chose a loopback between a UART controlled by the A53 cores and an R_UART controlled by the AR100. I’m not burning any bridges here, the shared mem solution is still available in case anyone wants to try it and look at possible benefits and downsides, but now we have to option to do both.

A Timer for the AR100

The third and final hurdle was getting a hold of a decent timer for the AR100. There is actually a timer peripheral (R_TIMER) in the A64 dedicated to the AR100, but unfortunately it is not timed by the AR100 CPU clock at 300 MHz. Instead, it is timed by the main oscillator at 24 MHz. This meas that the timer does not have enough resolution to cause stepping in the exact moment needed. But there is another solution, a tick timer facility in the OR1000 ISA . In Klipper, the implementation becomes very simple and even though the program will have to keep polling to check if time matches, the CPU is mostly idle regardless, so it should not make a difference.

More Work is Needed

Even though Recore now runs, the work on this started about a year ago, so the branch of Klipper that is was based upon is very outdated. Once Recore A5 is available in the shop, work will shift back to upstreaming the AR100 patches in Klipper so the work will be maintained. But at lest there is a way to print with the Recore boards, and that is a good starting point.

Like I mentioned in the videos, it looks like the AR100 is doing very well in terms of print speed compared to other solutions measured by Klipper.

The post Recore is Finally Printing! appeared first on www.iagent.no.