Hi everybody,

Last year I posted here a DYI design of a stepper motor analyzer that was based on teensy 4.0 (600Mhz processor, at $20 a piece) and a 3.5 Nextion smart TFT(~$35).

Since then I worked on and off on a simpler and less expensive design and it works even better. This design uses a 3.5" 'dumb' TFT with a capacitive touch, and ~$3 'blackpill' STM32F401CE board from Ali Express.

The hardware design is trivial, with a blackpill module, two small current sensors and a EEPROM to save the settings, and it has a 40pin connector that plugs into the TFT screen. All the heavy lifting, including the signal processing, extraction of stepper measurements and user interface are done by the firmware.

Github repository and documentation are here https://github.com/zapta/simple_stepper_motor_analyzer and electrical schematic is here https://github.com/zapta/simple_stepper_motor_analyzer/blob/master/kicad/stepper_analyzer-sch.pdf .

I may be able to make a few available for cost, especially for developers that want to add functionality (C++, Platformio under VSCode, programming/debugging using stlink V2). Flashing of new boards can be done with DFU software over USB, no tools of dongles required).

If you want to build one, or ten, or a thousand and have questions, I will be happy to answer. The connectors BTW are duet2 compatible.

@deckingman said in Question about the quality of the Duet software..:

it means graduates of either Oxford or Cambridge universities.

Thanks @deckingman. This explains why when I searched for Oxbridge University I got this

This is an experimental project to have large led indicators with the printer status using data sniffed from the PanelDue serial communication. The pictures below are of the current (second) prototype. It is based on a Teensy LC with an Arduino sketch, an isolated 24/5V DC DC, a small strip of WS2812B RGB leds, and a diodes and a resistor.

Overall I find it to be very useful. When the printer is busy the light is white which also helps the Wyze webcam at night. Once the print is completed and the extruder cools down to 70C the light changes to green which indicates that it's safe to turn off.

Programming is done via the Teensy USB connector and the USB cable can be removed in normal operation. I chose the Teensy LC because it provides a good balance between cost, computing power, easy to install and use IDE, and having a 5V output to drive the the WS2812B LEDs. To make the thing working on both the DC/DC and USB power (for development), I cut the VIN/VUSB link at the backside of the teensy and am using two Schottky diodes the OR the 5V from the two sources.

All the source files are available here: https://github.com/zapta/misc/tree/master/duet3d_monitor . I will add the kicad files one the PCB design is ready.

Next I will place everything on a small proper PCB and will replace the cheapo DC/DC with digikey 1951-3441-ND‎

This video shows a proof of concept of a duet WiFi remote monitor. The monitor displays the print progress and changes colors as the duet state changes (in this case from print to pause, cancel and idle).

https://vimeo.com/388175661

At it's current form it's crude but I hope that some creative programmers here can make something more useful and aesthetic.

The hardware is a fun off the shelf M5Stack Core. It's an ESP32 based Arduino with color screen, battery, charger, buttons, speaker and tons of I/O connectivity. The software polls the duet periodically via WiFi, extract the data it needs and displays it. It is based on the PanelDue json parser and full source code is here https://github.com/zapta/misc/tree/master/duet3d_buddy/arduino https://github.com/richard-mckenna/duet_buddy (repository moved, May 2021)

The M5Stack has very active community and comes with rich libraries that includes graphics and various widgets that can be useful for a duet monitor. Some graphic demo here https://youtu.be/po3pbBcOxzA?t=404

I am toying with the idea of having a public domain demo design of an inexpensive stepper motor analyzer so others can offer inexpensive kits or finished products, for example for 3D printers builders and tweakers.

The idea is to sense the current of the stepper motor coils, performa simple analysis in realtime and display useful information and graphs on a small screen (e.g. 1.8" color TFT).

This is what I have so far, a board with two +/-5A, AC/DC isolated current sensors (ACS70331) and a microcontroller (Teensy 3.2) that make sense of the signals and send the results to a computer via a serial port (the TFT screen is on order, should arrive in a few weeks).

Currently it decodes accurately full steps but there is sufficient data to interpolate fractions of steps using the current ratios.

Here is a picture of the prototype board (the two knobs are for testing only, not part of the final design)

And here is an example graph of extruder steps while printing (0.9deg, 3:1 gear). The large retraction at the end is the end of print retraction.

Should be easy to compute for example the actual max retraction, that is length of filament that was in the extuder and is now out, due to pressure advance, retraction etc. Other analysis can be for speed, acceleration, RMS current at high speeds and so on).

Had more progress with the analyzer's prototype. It now has a small display and shows information in real time. It shows current in both coils, number of quadrature state errors (e.g. if moving too fast for the stepper), the number of times the stepper was idle and the current step counter. Next I will try to show a graph on the display, of the step counter and/or of the coil currents. May also display aggregated values such as max current, RMS currents, speed, etc.

The prototype board with the display:

A close up of the display

The data the analyzer sends in real time via the USB port is also plotted on the computer. This graph shows the extruder steps while printing Calicat. The big deeps are retractions. The ripples is the the pressure advance (set to 1.5).

TL;DR, If you a regular here and would like to purchase a stepper motor analyzer please let me know. I can do a small at-cost run of up to 10 units.

The Raspberry Pico made headlines a few months ago so I decided to try porting the Simple Stepper Motor analyzer to it, and am happy with the results, so decided to have a small at-cost run of up to 10 units for regulars here that are interested.

This is a more compact design than the previous one, with a single PCB and components on one side and LCD screen on the other. Capabilities are the same but with possibly smoother display due to the larger RAM and faster CPU.

The cost per unit is $30 + actual post office fee to ship to your location from the US (It's expensive, can be $30+ to Europe), payment via Amazon gift card (can purchased online) at the time of shipping.

Note that I don't make any profit, give my time for free, and just hope to be reimbursed for the out of pocket expenses so please adjust your expectations regarding warranty and such

BTW, if you want do built it yourself, including commercially, this design is in the public domain and I hope to release the files and documentation in 2-3 weeks. (electronics, firmware, 3D models and user guide)

The 3D printed enclosure is not included and you will have to print it yourself. I will try to include the M2.5 threaded inserts.

The analyzer, as primitive as it is now, already helped me diagnose a problem. I often had a general issue of under extrusion so the extruder path was clean and fully functional. Looking at the E steps counter on the analyzer while printing one of the problematic prints, I notices this:

As you can see, the retraction was significantly longer than the unretraction which results general trend of the filament going OUT of the extruder.

That also caused errors in the tracking of the stepper steps so it was easy to sync to that point of time with a scope and see this:

The unretraction steps are too fast compare to what a that stepper with 24V supply can handle which results in reduced and distorted current patter through the coils.

Looking at my config.g I found this line which sets the max extruder speed.

M203 X15000 Y15000 Z3000 E15000

And reducing it to E1500 solved the problem (the upper limit of reasonable stepper signal on my printer is about E2000). If my calculations are correct this is about 25mm/sec on my extruder with 0.9deg and 3:1 gear reduction.

Hopefully we will have one day analyzers that will do all this process automatically or even Duet itself since the coil currents are available to it (not sure how though how much information the existing TMC drivers convey to the CPU).

Good news, 20 PCBs arrived from JLPCB with some preassembled components. I built one using a screen I had and it seems to work. Now I am waiting for the screen and other components for the first batch of 10 to arrive, should be here within 2-3 weeks. Once this batch is shipped and has no problems, I will work on the next batch.

As arrived from JLCPCB:

Fully assembled:

Enclosed:

A quick update: Still waiting for some components to arrive from china (current sensors, connectors, and Picos). I ordered sensors and connectors with aliexpress-standard-shipping but it's still on the way, same for the Picos from Seeed. Meanwhile I decided to use the waiting time and printed enclosures

I just installed Prusa Slicer 2.8 on Windows. It has a new top level tab structured with the new tab 'Physical Printer' which shows the Duet3D web dashboard. Very nice integration. The IP address is taken automatically from the upload setting.

Thanks @Phaedrux.

I like the automation aspect, that is, one click in the browser and a printed part a few hours later. Any creative idea for an automated workaround?

Or, should this be a feature request?

@Tinchus, I have a non Duet project where a servo needs to be quiet between moves and I solved it by stopping the signal to the servo (PWM output stays at zero volts) instead of pulsating. Potentially you can do the same with the Duet. E.g. by reconfiguring the IO point.

My gcode files includes a 1 hour preheating time that is injected by the Prusa Slicer's custom gcode (holding the bed at 100c to let the heat the chamber and stabilize the frame). This works well but makes the time estimations of the RRF significantly less accurate.

Is there a way to let RRF know about that heating period such it can handle it correctly in regard to the estimations? E.g. basing the estimations only on the behavior after the preheating period?

@aytact, I am using the Duet accelerometer with a 3D printed adapter. Easy to install and remove without changing the baby step setting.

https://forum.duet3d.com/topic/33664/custom-input-shaping-accelerator-board/7?_=1713546874157

Thanks @jay_s_uk ! This is exactly what I was looking for.

Are the schematic and firmware of the Duet3D IR height sensor available as open source? I couldn't find them at https://github.com/Duet3D.

https://www.filastruder.com/products/mini-differential-ir-height-sensor

@T3P3Tony, I see.

I am trying to find a way to speed up touch sensors such as BL Touch but this approach should apply also to other sensors types. My hypothesis is that if instead of a binary state they provide a small hysteresis-free continuous region around a known point, the meshing can be speed up significantly since it requires only minor Z adjustments during the scan to tack that point. Not much different from the mesh compensation during the actual printing.

Will see how it goes.

@T3P3Tony, with the current approach, you rely of the scale calibration of the sensor, or the K1 in the linear approximation below:

L[mm] = K0 + K1*SensorTicks

With this approach you are K1 agonistic since the Z measurement is inherently calibrated by the Z steps which is also what the printing process uses. In other words, you relax the requirements from the sensor, and at the same time, can still mesh faster than the traditional stop-and-probe.

Does this make sense?

EDIT: it's same concept as using a null meter instead of a volt meter.

@dc42, I was thinking about the Z probe and meshing issue.

Since you control also the Z while scanning in X,Y, instead deducing height in mm from the probe, you can just pick a certain probe measurement value and then, while scanning in X,Y, dynamically adjust the Z to maintain that level.

This will equal-height surface that is well calibrated to mm by the accuracy of the Z steps, and will still be must faster than the stop-and-probe approach of BL Touch.

BTW, the same approach can possibly also be used with your IR sensor, assuming that its differential mechanism can give you a on-target/above/below indication.

Does this make sense?