Logic Analyzer for Step Signals

From a discussion lately about which Firmware is generating the best signals for steppers I recognized that this was more about what people think should be done than looking at some data and saying here is a problem something must be done.

So I tried to get some data.

I own this: Logic16 but this Logic should also work.

It is a USB Logic Analyzer. The good thing about it is that it can stream the data to the PC in real time. So the time that can be recorded only depends on how much memory the PC has. The even better thing is that they supply an API to access this data directly.

Their software is extremely good. And they also record up to 10 billion samples. But I don't see the benefit of looking at thousands of step pulses that all look exactly the same.

I wrote a small program that takes the incoming data sample by sample and compares it with the last sample. If something changed in the signal the new value is stored. If there is no change then a counter is incremented to store the duration of that signal. This way I only have to save data whenever there is a Edge (low to High or high to low) on any of the 8 Signals.

I now connected Step and Dir signals for X,Y,Z and E (=8 signals) and did some measurements.

The first measurement was a simple homing of X,Y and Z. The next measurement was a small print (47 minutes print time). Both have been recoded at 16 million samples per second. Due to the storing of data only on edges the 47 minute print resulted in a 75 MB File. This file can also be compressed. Zip brings it down to 11 MB, bz2 down to 7.3 MB.

The print was on “normal” speeds. And the result looked good. The Firmware in the Prusa i3 was Marlin 1.0.0.

I also wrote a small application to do some basic statistics on the data. (I attached 2 files with all the statistics I computed so far)

The good news is the step pulse length is very constant. Interestingly the length of the step signal seems to depend on the Axis. The pulses on X and E are longer than the pulses on Y and Z.

Then I looked into speeds. I defined the speed as 1/time between the rising edge of two step pulses. The speed changes are last speed minus current speed with the sign ignored. I also ignore the Direction signal.

The data seems sane. The interesting fact here is the relative high max speed change values. The fact that marlin does up to 4 steps in one ISR might have something to do with this.

If anybody is interested in the software or the data. I can make them available.

Do you have any suggestions of what would be interesting statistics to try next? Direction changes, Acceleration? What information would help in making step generation better?
Or are there any reasons why this data is not helping improving the step generation algorithms?

For those not wanting to shell out $150, this also works nicely in SimulAVR: [reprap.org] Well, as long as you run on an AVR, because I'm not aware of a step-accurate simulator for ARMs.

I think statistics isn't up to the task. Here in Germany we have a saying like "Statistically, the lake is 20 centimeters deep on average, nevertheless the cow drowned".

Mapping these pulses to speed and geometry graphs would give useful data for investigating wether steps are evenly distributed and how unevenness results in geometric inaccurracies. Teacup is doing such stuff for quite a while already for regression-testing performance critical code sections. You can find some scripts for generating graphs in its testcases/ folder.

BTW., your statistics says you run at 9000 steps/s only; AFAIK in Marlin double/quadstepping kicks in at 12'000 steps/s earliest.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
Mapping these pulses to speed and geometry graphs would give useful data for investigating wether steps are evenly distributed and how unevenness results in geometric inaccurracies. Teacup is doing such stuff for quite a while already for regression-testing performance critical code sections. You can find some scripts for generating graphs in its testcases/ folder.

Do you mean this folder? In that folder I only found one script.

The principle seems to be very similar. Instead of a Logic Analyzer you use simuavr. You then do some magic that I could not completely decode and then feed the data into GtkWave to present a nice graphic, right?

So I understand you comment as suggestion to draw a nice curve showing the speed? /acceleration? over a print. That is a good Idea. The question I have here is how to analyze this. So I look at the graphic and search for parts of the curve that do not look right? like spikes, fast changes?

You don't happen to have example graphs that you decided to be good samples of such a curve?

Shouldn't there be a better way than looking at lines and let you guts decide?

Quote
JustAnotherOne
You then do some magic that I could not completely decode and then feed the data into GtkWave to present a nice graphic, right?

This "magic" is to rename signals by their functionality and to derive signals like accumulated position, speed in steps/second and mm/min from the step pulses. All back into a .vcd file for easy viewing in GtkWave (or another VCD viewer).

Quote
JustAnotherOne
You don't happen to have example graphs that you decided to be good samples of such a curve?

See here: [reprap.org]

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Quote
Traumflug
This will run 60 simulation seconds (which typically takes some 5 minutes wall clock time) and results in a file .processed.vcd.

For those willing to invest: The saleae Software can record more than 60 seconds in real time and has a viewer integrated. For those interested I could do such a measurement (Just tell me what you want to see) and share the data. The Software is a free Download.

Back on Topic:

The question was how can we get the most information out of this data.

Traumflugs answer is too look at the speed (steps/s) over 60 seconds when printing.

My Question is: What do we see there? As this is simulated data there is no influence due to Mass of print head or distortion on the line. But the curve does not look very clean to me. I attached the part of the shown curve that seems to have a spike, where is should be a very clean line. The resolution is not very good. So I can not say what we can see there. But if looking at the line is the analyzing part of this method then I would like to know if that spike is OK, and why?

Is should also be clear that this "looking at the speed/s line" is not practical for a longer measurement.

I can see that this helps in the early stages of a new move algorithm to check that the steps make sense. And the Steppers/the printer is not harmed by bad software.

But I'm more looking for a way to measure the quality (did not want to say smoothness) of the step generating. With such an objective measure we could do objective comparisons between the different firmwares.

That would raise the firmware developers awareness of the problems and we all would get better quality printing (Yeah!), right?