Anybody wants a stepper motor analyzer?

zapta

@dogma2k, it's not clear from 'only have the 3 other analyzers in operation' if you tried to monitor the motor that had noise with another analyzer.

Please try this two cases:

Operate the analyzer that gave you noise with another motor in and see if you still see noise with the new motor.
Operate the motor that gave you noise with another analyzer and see if you still see noise with the new analyzer.

This tell us if the problem is related to the motor and its driver or to the analyzer.

Dogma2k

@zapta
Sry I think the google translator didn't translate it the way I wanted it to.

I swapped the analyzer with several analyzers and each time the error (the artifacts) moved with it.
So no matter which stepper or driver is connected to this one analyzer, it always shows artifacts.

In addition, I shut down the analyzer with the artifacts and since then there have been no more delays in the other 3 analyzers during printing.

I hope google translates it now understandable

rjenkinsgb

@dogma2k said in Anybody wants a stepper motor analyzer?:

I swapped the analyzer with several analyzers and each time the error (the artifacts) moved with it.
So no matter which stepper or driver is connected to this one analyzer, it always shows artifacts.

That sounds like some kind of short circuit between the motor side connections and the internal electronics - a faulty current sensor IC or some kind of bridge or shorted pins on the circuit board.

Can you check with a multimeter (on resistance) between the motor connector pins and USB ground, to see if there is an obvious cross-connection, with all cables disconnected?

zapta

@dogma2k, the blue channel is made of this connector, U2 current sensor, capacitor c2 and the CHB input of the Pico. I suggest to inspect it carefully for anything strange.

Also, when you swap motors and analyzers, if the cables stayed with the same analyzer, I suggest to inspect the cable and connections as well.

Dogma2k

@zapta

The cables were always different when I exchanged the analyzer.
In the picture you can see from the red arrows how I rotated the analyzers (all) and each time the noise moved with it.

!!This is an old image and is for illustrative purposes only!!

So start top left -> bottom left -> bottom right -> top right. Thus, the possibly defective analyzer was connected to all possible cables and motors.
As I said, the error has migrated and did not remain at the top left.

I'll probably just get a new analyzer. Since I find it strange that if the possibly defective analyzer is not connected, all the other three analyzers work without problems

Dogma2k

@rjenkinsgb
I thought about that today but didn't find the time.
I'll probably get another analyzer. Then I can calmly check the "possibly defective".

zapta

Apparently the analyzer can also be used as a magnetometer. Placing a magnet at the upper left corner gives a reading at Coil A. Positive values means magnet's north pole faces the screen and negative values magnet's south pole.

Useful for example when matching the magnet polarity of a Klicky probe. For higher sensitivity, open the base and place the magnet directly on the sensor.

The current sensor doesn't seems to have memory or hysteresis so I don't think it is effected long term.

nyaru

Hi.
I have made the analyzer using TMCS1101A4B.
It is very nice. Thanks for developing it
I took a video of it in running.
https://youtu.be/eDaxUO8Hbqo?t=115

And I have questions.

"Current Patterns" and "Phase Patterns" screens are choppy, is this normal?
It sample data for 20ms, but it feels like 2fps.
Is this due to the heavy load of data post-processing on the Raspberry Pi Pico?
The ACS70331 has a bandwidth of 1MHz, whereas the TMCS1101A4B has a bandwidth of 80KHz.
I think 80KHz is sufficient for measuring stepping motor pulses, is that correct?

zapta

Hi @nyaru, I am glad that it works for you.

The current and phase pattern, which use signal capturing, have intentional delay between screen updates to allow the user to view the signal. It could update at a higher rate but would be difficult to use.

https://github.com/zapta/simple_stepper_motor_analyzer/blob/main/platformio/src/ui/adc_capture_util.cpp#L55

The signal is sampled at 100Khz. I am not an expert but by Nyquist–Shannon, 80Khz should be sufficient and maybe theoretically even better than 1Mhz due to lower probability of aliasing. I never used the TMCS1101A4B I believe it should just as fine for this application.

Keybored

Hi @zapta ,I'm currently adapting the schematic and firmware for a different sensor, the MCA1101-5-5 (available on Mouser). They are +-5A, 350 mV/A, 1.5 MHz and they use the SOIC-16 package, but that's not an issue.
The question I have regards the firmware. I've read the source, and to my understanding, I should change static const SensorSpec GMR_2P5_SENSOR("G2P5A", 5000, 0.35) in hardware_config.cpp, and possibly the initial voltage offset (or is that handled by the Zero calibration?). I should also change the Y-axis values of many of the graphs, but that's easy. Do I have to adjust anything else? (don't bother reading the datasheet if you don't have time, I just need to know if there are other user-defined parameters or constants).
I'll fork the repo once I'm finished
Cheers!

zapta

@keybored, I looked briefly at the chip you linked and it may be doable. I would focus first on the hardware aspects and worry latter about the firmware.

The chip seems to require 5v nominal so if you can't run it on 3.3V you need to power it from the 5V rail and make sure that its analog output doesn't go beyond the 3.3V that is accepted by the Pico's input. Maybe add a resistor in series (e.g. 2K) to limit the current when the analog output goes beyond 3.3v? Or maybe add also a clamping diode to 3.3V if we can't rely on the Pico's internal diodes? Or maybe use a voltage divider (this will increase the 350mv/A but you can compensate in the firmware).

As the max Y range of the firmware, I am not sure if 5A is better than 2A because most hobby steppers are < 2A and you will get better resolution on the screen. Also, if the no current output voltage is 2.5V and it can be measured only up to 3.3V, your max range will be only (3.3-2.5)/0.35 = 2.3V

Anyway, I would start with tackling the 5V aspect. let me know if you will have more questions.

EDIT: looking at the datasheet, the zero current voltage is 2.175V and not 2.5V as I assumed above. In this case, you can achieve +/-3A with the 3.3V adc input of the Pico.

Keybored

@zapta
Thanks for the input! I was thinking about a voltage divider too. That should be extremely easy to compensate for. About the output voltage, I've yet to find how high it goes (shouldn't be more than 4V if we consider the 350mV/A range plus the offset).

The main idea behind this adaptation is to use it above the +/-2.5A range on Nema23 and over. +/-3A would be acceptable but not ideal. I perfectly agree on tackling the 5V issue first. I'm quite sure a divider would work fine with the relatively high frequency of the signal, but insight on that would be much appreciated.

I'm still unsure if the firmware is as easy to adapt as you say. Plus, now that you pointed out, I'll probably keep the 2.5A scale.

Thanks for the help and I'll update you with the schematics

Keybored

@zapta Slight change of plans: I found the same sensor, but that works on 3.3V. It's still ±5A, with a lower resolution (230mV/A compared to 350mV/A). It has a lower offset (1.5V) and the full range can be read by the Pico's 3.3V I/O. https://www.mouser.it/ProductDetail/ACEINNA/MCA1101-5-3?qs=PzGy0jfpSMs%252BNw%2FnqBFIdA%3D%3D

It's (theoretically speaking and pinout aside) a direct replacement for the ACS70331. My question now is: firmware-wise, what do I have to adjust? If I understand this correctly, I just have to adapt
//static const SensorSpec GMR_2P5_SENSOR("G2P5A", 2500, 0.4)
to suit my specs
//static const SensorSpec GMR_2P5_SENSOR("G2P5A", 5000, 0.23);.
Should I also uncomment //constexpr int kMaxMilliamps = 2500; and set it to 5000 to read the full scale?
For now, I'm just thinking about the analyzer changes, UI and graphs axis can be adjusted later.
Also, what about the offset? It's the same as the ACS70331, so we should be alright?
Thanks in advance for your time and patience. I really like the project and I want to keep it alive.
Cheers!

zapta

@keybored, I would suggest to start with just changing 0.4 to 0.23 and run it as is. The Reset function in the setting page should take care of the different offset level.

Once that works, if you would like to increase the range (and decrease the screen sensitivity which I am not sure is useful for most 'normal' stepper motors), you can look into increasing the range. That would require adding in a few places additional Y scale definitions for 5000ma similar to this

https://github.com/zapta/simple_stepper_motor_analyzer/blob/main/platformio/src/ui/osciloscope_screen.cpp#L17

Keybored

@zapta Thanks! I'll change the board design and proceed on this track then. Do you think the lower sensing resolution will impact the quality of the readings?

zapta

@keybored, I don't expect the lower sensitivity to be significant.

Of course, I don't know for sure since I never used that IC.

zapta

I am trying now a new approach, a BLE Stepper Motor Analyzer. It still at an early stage, but so far looks feasible. Imagine a small widget, smaller than a matchbox, with 4 pass through stepper motor wires. The widget harvests a small amount of power from the wires (~100mw) to power a small microcontroller (Nordic NRF52832) that monitors stepper signals, extracts information such as steps/speed/waveforms, and sends it wirelessly via BLE to an app on a computer, smart phone, or even to a DWC plugin (which uses Web Bluetooth).

I don't know if it's all possible but initial tests look good. With a NRF52832 that samples two analog channels and sends the extracted data to a PC via bluetooth (max sampling rate I could get is 40Khz per channel compared to 100Khz on the Simple Stepper Analyzer). Power harvesting also looks feasible with a four phase full rectifier bridge, a small capacitor and a 5-30V -> 3.3 DC/DC converter. The energy is available as long as the stepper is energized, regardless if it moves or not and on what microstep/phase it happened to stop. Could also add a small battery rechargeable or not, if needed.

As for the client software, I am thinking of a reference python client that people can use to create desktop apps or as reference design for mobile and other clients.

As I said, it's still at an early phase and I don't know for certain that this is feasible.

Any thoughts?

oliof

@zapta I'll take five.

zapta

@oliof said in Anybody wants a stepper motor analyzer?:

@zapta I'll take five.

Will keep it in mind. My preference would be to provide it to a few developers that will build real apps (for desktop, mobile, or web bluetooth).

One challenge I hit is how to calibrate zero current if the MCU is not powered when the current is zero.

zapta

Had more progress with the BLE stepper probe and was able to display on a PC a real time step and speed graphs over BLE (using python/Bleak/Pyqtgraph and the PC side). Sill need to do some tests, e.g. of the energy harvesting, but it feels feasible. The MCU and the radio consumes about 3ma and the current sensors about 5ma each (all at 3.3v), for a total of ~40mw. This is the current schematic (not tested):

If anybody thinks that I am doing something terribly wrong (e.g. damaging the Duet's driver) now it's the time to speak

Anybody wants a stepper motor analyzer?

Robert J.