Quax
Posts: 26
Joined: Mon Jul 26, 2021 5:51 am

Speed measurement on a Triton router

Mon Jul 26, 2021 11:30 am

Since my English skills are not exactly perfect, I will try Google and hope my request remains understandable ...

I would like to use a Raspberry Pi Pico to implement a speed display for a Triton router in the MicroPython programming language.
The router is built into a milling table, so the speed control scale is covered. Therefore, the current speed should be shown on an external display.
The router has a speed control. The original actual value acquisition of the speed takes place via a Hall sensor and a magnet mounted on the rotor shaft. A maximum of 30,000 rpm is to be expected.
In contrast to the often described way of counting the revolutions per second, I would like to record the duration of a revolution (period). I am hoping for stable, reproducible measured values from this, especially at low speeds
as well as a simple detection of a standstill (speed = 0).
I would like to use the "utime.ticks_us" function to record the period duration with sufficient accuracy (resolution 1 microsecond).
The actual value acquisition should take place via the existing magnet and an additional Hall sensor to be installed.
The same input (additional Hall sensor) is used for starting and stopping the period measurement. I suspect that IRQ routines are required for both operations. The period duration measurement should start with the first positive edge of the Hall sensor. After one revolution of the motor shaft (next positive edge), the "ticks" that have accumulated since the start are to be calculated and transferred to a variable. This variable is to be used outside of the IRQ routines for the moving average and for calculating the speed.
The period duration / speed measurement would therefore only take place every 2 revolutions (but this is not a problem for the application).

I am almost 66 years old and in my professional life I have gained experience in programming industrial controls (Allan Bradley, Moeller / Eaton, Keyence, Omron) but also in programming in Basic and Pascal.

I would be very happy to receive support, relevant advice and contacts.

horuable
Posts: 163
Joined: Sat Mar 06, 2021 12:35 am

Re: Speed measurement on a Triton router

Mon Jul 26, 2021 1:06 pm

Honestly, I wouldn't use ticks_us() for this, but rather take advantage of hardware present on RP2040, specifically counter capabilities of PWM blocks, or even PIO if PWM would be insufficient. Take a look at a module I've made that simplifies using PWM as a counter: https://github.com/phoreglad/pico-MP-mo ... PWMCounter
In the examples folder, you'll find a program for measuring pulse width.

hippy
Posts: 10530
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Speed measurement on a Triton router

Tue Jul 27, 2021 12:41 pm

I would use a PIO to increment decrement the X or Y register during the revolution and then push that.

30,000 RPM is 500 RPS, one revolution per 2ms at the fastest rate which should be easily handled by polling and checking if there's any data in the sm.get() queue, and should work with interrupts.

Code: Select all

from   machine import Pin, PWM
from   rp2     import asm_pio, PIO, StateMachine
import time

GPIO_PIN = 4

btn = Pin(GPIO_PIN, Pin.IN, Pin.PULL_UP)

@asm_pio()
def PulseIn():
  set(x, 0)           # X = 0;
  wait(0, pin, 0)     # Do {} While ( pin == 1 );
  wait(1, pin, 0)     # Do {} While ( pin == 0 );
  label("loop")       # Do
  jmp(x_dec, "next")  #   X--;
  label("next")
  jmp(pin, "loop")    # While ( pin == 1 );
  mov(isr, x)         # Push(X);
  push(isr, block)
    
sm = StateMachine(0, PulseIn, in_base=btn, jmp_pin=btn)
sm.active(1)

# This is just for testing. We generate a pulse on an output pin using PWM
# which just happens to be the same pin we are measuring

pwm = PWM(Pin(GPIO_PIN, Pin.OUT))
pwm.duty_ns(2_000_000) # 2ms

while True:
  # Note the count is decremented in the PIO routine so it will be a
  # negative value. We need to make it a positive value.
  cnt = (1 << 32) - sm.get()
  tms = cnt / 62500
  rps = 1_000 / tms
  rpm = rps * 60
  print("{} counted, {} ms rev, {} rps, {} rpm".format(cnt, tms, rps, rpm))
  time.sleep(1)

Quax
Posts: 26
Joined: Mon Jul 26, 2021 5:51 am

Re: Speed measurement on a Triton router

Wed Jul 28, 2021 4:32 am

Hello horuable,
Thank you for your quick response. I would like to try that!
I understand your solution to mean that the module "PWMCounter.py" has to be integrated into a library or a library folder so that this module can be called in the actual program "Frequency_measurment".
I use the Thonny IDE and have searched the Internet for ways to integrate the module into the libraries. Unfortunately, the paths shown there totally confused me. Can you describe the way for me?

Hello hippy, thank you very much too. I copied your program in Thonny first, it runs without errors. I still have to connect the onput with the output de Pico (was too tired last night). Then get in touch ...

horuable
Posts: 163
Joined: Sat Mar 06, 2021 12:35 am

Re: Speed measurement on a Triton router

Wed Jul 28, 2021 4:38 pm

The simplest way to get a module on the Pico using Thonny is to create a new file, copy the contents of PWMCounter.py (using Raw mode for best results - can be changed at the top right of code window) from GitHub, paste, and save it to Pico as PWMCounter.py (who would've guessed, right? :D)

Then to use the module in another program do:

Code: Select all

from PWMCounter import PWMCounter
Just like frequency_measurement.py does at the beginning.

Also, you should probably take a look at pulse_width_measurement.py, as it better fits what you have described earlier.

Quax
Posts: 26
Joined: Mon Jul 26, 2021 5:51 am

Re: Speed measurement on a Triton router

Wed Jul 28, 2021 7:51 pm

First of all, thank you very much for your effort.
If I understand you correctly, this means that the modules are only saved on the Pico.
Is there a possibility to expand the Thonny libraries with these modules so that they are available on demand in Thonny (similar to "machine", "utime" ...) and are only written to the Pico when needed?

horuable
Posts: 163
Joined: Sat Mar 06, 2021 12:35 am

Re: Speed measurement on a Triton router

Wed Jul 28, 2021 9:53 pm

Yup, every module has to be present on Pico to be used in programs. I have no idea if Thonny can upload any modules to Pico by itself, I've never tried to do that. The modules you mentioned are not really a part of Thonny libraries, but they're baked into MicroPython firmware to be always available on the Pico, even though they do not appear as separate files on the filesystem.
You can always save the module on your computer and copy it using Thonny to the Pico whenever you'll need it. I know it's not as convenient as Thonny doing it automatically, but I don't think there's an alternative (I'd be happy to be proven wrong though). On the other hand, there's enough flash memory on Pico to store multiple modules and/or programs, so unless you'll need to store lots of data from a program there's no downside to just leaving the modules there, save for visual clutter when trying to find a specific file.

Quax
Posts: 26
Joined: Mon Jul 26, 2021 5:51 am

Re: Speed measurement on a Triton router

Thu Jul 29, 2021 5:43 am

Ok, I understood. Thanks for the explanation, the fog has cleared a little. If by chance I should actually come across a possibility to integrate modules in Thonny, I will be happy to inform you.
But now I will first try out the various proposed solutions. It will probably take a while, because I would like to understand the programs too.
Still, I'm still brooding over my original idea (capture ticks in one (or 2?) IRQ. Would like to learn more about this IRQ story.
Thanks again for your help, I think it's great!

hippy
Posts: 10530
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Speed measurement on a Triton router

Thu Jul 29, 2021 12:35 pm

Quax wrote:
Thu Jul 29, 2021 5:43 am
If by chance I should actually come across a possibility to integrate modules in Thonny, I will be happy to inform you.
I believe you are misunderstanding how libraries are; none of them are 'integrated into Thonny'.

Libraries are either baked into MicroPython firmware itself or loaded from the Pico file system. Thonny has the ability to place a MicroPython module into the Pico file system but doesn't do this automatically.

Baking your own MicroPython modules into the MicroPython firmware is pretty simple -

Git clone the MicroPython source
Place your own MicroPython modules in '~/pico/micropython/ports/rp2/modules'
Build the RP2 port and the modules will be baked in to the MicroPython firmware.uf2
Flash that firmware.uf2 to your Pico

Quax
Posts: 26
Joined: Mon Jul 26, 2021 5:51 am

Re: Speed measurement on a Triton router

Thu Jul 29, 2021 2:18 pm

Hello horuable, I inserted the PWMCounter module and the sample program frequency measurement one after the other in Thonny and saved them in the Pico.
Indeed, it works.
But: I changed the frequency of the PWM frequency generator on a trial basis and get very strange measurement results:

Frequency generator Displayed result
980 980-981
990 995-996
996 1009-1010
998 1016-1017
999 1004-1005
1000 999 - 1000
1002 1016-1017
1004 1016-1017
1010 1028-1029

What can that be? Does the measuring time (start or stop time) fluctuate inadmissibly?

Quax
Posts: 26
Joined: Mon Jul 26, 2021 5:51 am

Re: Speed measurement on a Triton router

Thu Jul 29, 2021 2:20 pm

Hello Hippy:
was really of the opinion that libraries / modules are integrated in the Thonny-DIE and are only loaded into the Pico when required (using the import command).
Many thanks to you too! I'm afraid the time of confusion could last longer!

horuable
Posts: 163
Joined: Sat Mar 06, 2021 12:35 am

Re: Speed measurement on a Triton router

Thu Jul 29, 2021 3:08 pm

Due to how PWM works the generated frequency is sometimes slightly different than what is entered in pwm.freq() call. The result that you see is the actual, measured frequency that is really generated by the PWM (I've checked it with an oscilloscope).
The single Hz differences are due to how this method of measuring frequency works. With default settings, it has a maximum resolution of 4 digits, which in this case corresponds to 1 Hz, so if the frequency is not perfectly divisible by 1 it will sometimes show one count up or down. To achieve higher resolution this method requires longer acquisition times, for example, to get 5 digits (so a single decimal digit for frequencies below 10 kHz) the sampling time has to be set to 10 s. You can try it by changing sampling_time variable (keeping in mind that it's in ms).

All in all, what you see is very reasonable and means everything works just as it's supposed to.

hippy
Posts: 10530
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Speed measurement on a Triton router

Thu Jul 29, 2021 5:06 pm

horuable wrote:
Thu Jul 29, 2021 3:08 pm
Due to how PWM works the generated frequency is sometimes slightly different than what is entered in pwm.freq() call.
I would be less kind than that and say the .freq() implementation is unfit for purpose. Whatever it is meant to achieve doesn't work, but one can get a near perfect result with a simpler implementation.

horuable
Posts: 163
Joined: Sat Mar 06, 2021 12:35 am

Re: Speed measurement on a Triton router

Thu Jul 29, 2021 5:45 pm

I'm not sure what you mean. Unfit for what purpose? Changing PWM frequency? I'm afraid it's the only way available. Showing how the module works? PWM is the simplest way to generate a signal with a known frequency, even if it's not perfect.

hippy
Posts: 10530
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Speed measurement on a Triton router

Fri Jul 30, 2021 11:41 am

horuable wrote:
Thu Jul 29, 2021 5:45 pm
I'm not sure what you mean. Unfit for what purpose? Changing PWM frequency?
Unfit in the sense that it often doesn't produce the frequency closest it could to what was asked for, the frequency generated jumping up and down as the frequency asked for increases or decreases.
horuable wrote:
Thu Jul 29, 2021 5:45 pm
PWM is the simplest way to generate a signal with a known frequency, even if it's not perfect.
I am not criticising PWM per se, only the machine.PWM.freq() implementation which is far from ideal.

There was a thread discussing this issue and I'll include a reference when I find it.- not needed with the example code I have added below.

You can test it yourself by varying frequency with .freq() and measuring what it generates.

Added : Or ...

Code: Select all

from machine import Pin,PWM

PWM_PIN = 4

pwm = PWM(Pin(PWM_PIN, Pin.OUT))
for hz in range(1800, 1860, 10):
  pwm.freq(hz)
  print("Wanted {} Hz : Generating {} Hz".format(hz, pwm.freq()))

Code: Select all

Wanted 1800 Hz : Generating 1808 Hz
Wanted 1810 Hz : Generating 1811 Hz
Wanted 1820 Hz : Generating 1851 Hz
Wanted 1830 Hz : Generating 1903 Hz         <---
Wanted 1840 Hz : Generating 1854 Hz
Wanted 1850 Hz : Generating 1851 Hz
That one I marked is ridiculous. But others are also further away from where they could be. Wanting 1840 generates 1854 when we can see 1851 is available and would be closer. Same too when wanting 1820 and it generates 1851 when 1811 is available and is closer. In fact there are values which are available but not shown which would be closer still.

Stepping 1 Hz shows how completely 'all over the place' the implementation is -

Code: Select all

Wanted 1800 Hz : Generating 1808 Hz
Wanted 1801 Hz : Generating 1808 Hz
Wanted 1802 Hz : Generating 1808 Hz
Wanted 1803 Hz : Generating 1827 Hz
Wanted 1804 Hz : Generating 1804 Hz
Wanted 1805 Hz : Generating 1808 Hz
Wanted 1806 Hz : Generating 1808 Hz
Wanted 1807 Hz : Generating 1811 Hz
Wanted 1808 Hz : Generating 1808 Hz
Wanted 1809 Hz : Generating 1815 Hz
Wanted 1810 Hz : Generating 1811 Hz
Wanted 1811 Hz : Generating 1811 Hz
Wanted 1812 Hz : Generating 1870 Hz
Wanted 1813 Hz : Generating 1827 Hz
Wanted 1814 Hz : Generating 1851 Hz
Wanted 1815 Hz : Generating 1860 Hz
Wanted 1816 Hz : Generating 1870 Hz
Wanted 1817 Hz : Generating 1851 Hz
Wanted 1818 Hz : Generating 1851 Hz
Wanted 1819 Hz : Generating 1851 Hz
Wanted 1820 Hz : Generating 1851 Hz
Wanted 1821 Hz : Generating 1837 Hz
Wanted 1822 Hz : Generating 1837 Hz
Wanted 1823 Hz : Generating 1870 Hz
Wanted 1824 Hz : Generating 1863 Hz
Wanted 1825 Hz : Generating 1827 Hz
Wanted 1826 Hz : Generating 1827 Hz
Wanted 1827 Hz : Generating 1827 Hz
Wanted 1828 Hz : Generating 1849 Hz
Wanted 1829 Hz : Generating 1914 Hz
Wanted 1830 Hz : Generating 1903 Hz
Wanted 1831 Hz : Generating 1903 Hz
Wanted 1832 Hz : Generating 1851 Hz
Wanted 1833 Hz : Generating 1870 Hz
Wanted 1834 Hz : Generating 1837 Hz
Wanted 1835 Hz : Generating 1851 Hz
Wanted 1836 Hz : Generating 1837 Hz
Wanted 1837 Hz : Generating 1837 Hz
Wanted 1838 Hz : Generating 1870 Hz
Wanted 1839 Hz : Generating 1870 Hz
Wanted 1840 Hz : Generating 1854 Hz
Wanted 1841 Hz : Generating 1887 Hz
Wanted 1842 Hz : Generating 1887 Hz
Wanted 1843 Hz : Generating 1854 Hz
Wanted 1844 Hz : Generating 1851 Hz
Wanted 1845 Hz : Generating 1851 Hz
Wanted 1846 Hz : Generating 1929 Hz
Wanted 1847 Hz : Generating 1849 Hz
Wanted 1848 Hz : Generating 1851 Hz
Wanted 1849 Hz : Generating 1851 Hz
Wanted 1850 Hz : Generating 1851 Hz
Wanted 1851 Hz : Generating 1893 Hz
Wanted 1852 Hz : Generating 1866 Hz
Wanted 1853 Hz : Generating 1866 Hz
Wanted 1854 Hz : Generating 1860 Hz
Wanted 1855 Hz : Generating 1929 Hz
Wanted 1856 Hz : Generating 1914 Hz
Wanted 1857 Hz : Generating 1893 Hz
Wanted 1858 Hz : Generating 1929 Hz
Wanted 1859 Hz : Generating 1860 Hz
Extra Added : Testing my own machine.PWM.freq() implementation shows I can generate each of those frequencies exactly as asked for.

Quax
Posts: 26
Joined: Mon Jul 26, 2021 5:51 am

Re: Speed measurement on a Triton router

Sun Aug 01, 2021 2:50 pm

Hello horuable, hello hippy,
I very much hope that there will be no quarrel about this issue!
I tested the module PWMcounter and the example frequency measurement from horuable again in the range 980 - 1015 Hz, in 5 Hz steps (frequency setpoint PWM / measured value):
980 / 980-981
985/985
990 / 995-996
995/1010
1000/1000
1005/1009
1010/1029
1015/1015
I repeated this series of measurements several times, the results are reproducible. However, this also means that there is no accidental error, but a systematic error (although I cannot explain the cause). The jumps from 995 Hz to 1000 Hz and from 1010 Hz to 1015 Hz are particularly interesting. Here the measured values ​​would change, so to speak, "in the wrong direction".
I will try to use a frequency meter to find out whether the PWM generator or the measuring routine is causing the error.
Horuble himself writes that part of the error could be in the resolution of 1 Hz (+/- 1 Hz!) And that the time base should be increased to 10 seconds for such low measuring frequencies. However, this would be of little practical use when setting a speed.
That is why I prefer the measurement using period measurement at such low speeds / frequencies (many motors or manual applications are even significantly lower in frequency).
My suggestion: The first positive edge of the Hall sensor triggers an IRQ that records the current "start time" via "thicks_us". After a complete revolution, an IRQ should be triggered again via the same input, which then determines the difference between the current "time" minus the "start time" and transfers it to a variable outside the IRQ routines.
In the third rotation (i.e. up to the 3rd positive edge at the input), the Pico continues to process its main program outside of the IRQ routines (e.g. calculation, smoothing and display of the measured values). Then the process starts all over again. One revolution is always used for data acquisition and one revolution for calculation / display.
Perhaps it is also possible to use a software D-flip-flop (as a frequency divider 2: 1). This would mean that the above-mentioned first edge (as a positive edge) would start the 1st IRQ while the negative edge could start the 2nd IRQ ???
I would be very happy if you could help me with this solution (maybe also by establishing contacts with the appropriate forum members).

hippy
Posts: 10530
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Speed measurement on a Triton router

Sun Aug 01, 2021 4:47 pm

Quax wrote:
Sun Aug 01, 2021 2:50 pm
I will try to use a frequency meter to find out whether the PWM generator or the measuring routine is causing the error.
If using .freq() to set the frequency then that is almost certainly causing issues. It wasn't so much a quarrel as pointing out that .freq() isn't anywhere near as good as it should be, which may not be widely know.

What you want generated by .freq() often won't be what is generated. It's therefore impossible to say if any odd reading is a result of .freq() issues or something else.
Quax wrote:
Sun Aug 01, 2021 2:50 pm
My suggestion: The first positive edge of the Hall sensor triggers an IRQ that records the current "start time" via "thicks_us". After a complete revolution, an IRQ should be triggered again via the same input, which then determines the difference between the current "time" minus the "start time" and transfers it to a variable outside the IRQ routines.
That's what my earlier PIO example does without the faff of having to call interrupts and without having to use ticks_us.

While your proposal might be perfect in a deterministic system, using MicroPython makes it a very non-deterministic system. Using PIO gives back that determinism. It should I believe be able to time each revolution with 0.02us resolution, which is why I consider it the best and most appropriate solution.

If you do want to do it your way, and it's worth it for the experience anyway -

Code: Select all

from   machine import Pin, PWM
from   rp2     import asm_pio, PIO, StateMachine
import time

GPIO_PIN = 4

btn = Pin(GPIO_PIN, Pin.IN, Pin.PULL_UP)

timing    = False
startTime = 0
elapsedUs = 0

def Irq(pin):
    global timing
    global startTime
    global elapsedUs
    now = time.ticks_us()
    if timing:
        timing = False
        elapsedUs = now - startTime  # Should be time.diff or something to avoid wraparound bugs
    else:
        startTime = now
        timing = True

btn.irq(trigger=Pin.IRQ_RISING, handler=Irq)

# This is just for testing. We generate a pulse on an output pin using PWM
# which just happens to be the same pin we are measuring

pwm = PWM(Pin(GPIO_PIN, Pin.OUT))
pwm.freq(1_000)
pwm.duty_ns(1_000_000) # 1ms = 1kHz, 1,000 RPS, 60,000 RPM

while True:
    if elapsedUs > 0:
        tms = elapsedUs / 1_000
        rps = 1_000 / tms
        rpm = rps * 60
        print("{} ms rev, {} rps, {} rpm".format(tms, rps, rpm))
        time.sleep(1)
Where the PIO example is rock-solid, repeatedly returns only one accurate reading every time -

Code: Select all

1.0 ms rev, 1000.0 rps, 60000.0 rpm
The above interrupt handling is all over the place -

Code: Select all

0.992 ms rev, 1008.065 rps, 60483.87 rpm
0.998 ms rev, 1002.004 rps, 60120.23 rpm
0.996 ms rev, 1004.016 rps, 60240.96 rpm
8.027 ms rev, 124.5795 rps, 7474.772 rpm         <=====
1.001 ms rev, 999.0009 rps, 59940.06 rpm
0.9969999 ms rev, 1003.009 rps, 60180.54 rpm
0.9940001 ms rev, 1006.036 rps, 60362.17 rpm
That really anomalous result I marked is a result of MicroPython doing garbage collection.

Sure, it's theoretically possible to avoid garbage collection and minimise its effects, possible to filter out erroneous results without affecting genuine ones with a clever algorithm, but it's much better not having to, to have perfectly accurate results in the first place.

horuable
Posts: 163
Joined: Sat Mar 06, 2021 12:35 am

Re: Speed measurement on a Triton router

Sun Aug 01, 2021 5:45 pm

Disclaimer: Writing this post took me waayyyy longer than it should and hippy was first, but here it goes...
hippy wrote:
Fri Jul 30, 2021 11:41 am
Unfit in the sense that it often doesn't produce the frequency closest it could to what was asked for [...]
In that case, I totally agree. I've noticed that before and it seemed extremely weird, but I never needed an exact PWM frequency so never investigated that. Thank you very much for showing me what to expect and how far the actual frequency can be from what was requested. I will certainly keep that in mind in the future. I'm also considering changing the PWMCounter example to use something that can generate more predictable frequencies (probably with PIO) to avoid confusing anyone who will want to use them.
Quax wrote: I will try to use a frequency meter to find out whether the PWM generator or the measuring routine is causing the error.
See the post by hippy above yours. It's due to how pwm.freq() works that makes it output frequencies deviating from what was requested. I've also verified it with an oscilloscope, as mentioned earlier.
Quax wrote: And that the time base should be increased to 10 seconds for such low measuring frequencies. However, this would be of little practical use when setting a speed.
I've never said it's the best way of measuring frequency. To be honest it's rather terrible when considering lower frequencies (and 1 kHz is not that high). There are way better types of frequency counters that could be realised with Pico hardware, I've even posted my implementation of such device (you can search for Reciprocal Frequency Counter on this forum if you want).
Quax wrote: That is why I prefer the measurement using period measurement
And that's why I said you'd be better looking at pulse width measurement that will be way better suited for what you want to achieve.

As for your suggestion, I'd advise against using IRQ and ticks_us() if only because using software for timing seems like a poor idea, especially when there are several hardware solutions that will almost certainly give better results. When I think of it, the solution proposed by hippy at the beginning of this thread is probably the best approach. I'd slightly modify it so that every period will be measured and I'd also get rid of blocking sm.get() call so that a timeout can be used to detect zero speed/stall condition.

hippy
Posts: 10530
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Speed measurement on a Triton router

Sun Aug 01, 2021 6:40 pm

horuable wrote:
Sun Aug 01, 2021 5:45 pm
When I think of it, the solution proposed by hippy at the beginning of this thread is probably the best approach. I'd slightly modify it so that every period will be measured and I'd also get rid of blocking sm.get() call so that a timeout can be used to detect zero speed/stall condition.
There is now official support for checking if there is anything in the sm.get() queue before stalling on that sm.get() ... sm.rx_fifo().

I don't particularly like the naming but ho hum. I used sm.any() to match Pico UART module functionality in my own proof of concept code when I had to provide it myself. I would have used '.isavailable()' for both to match PySerial for Python but fighting 'MicroPython incompatibility' seems a lost cause.

But it does mean flushing to get the latest data, and timing-out when there has been no data, can be done in the main loop. Something like ...

Code: Select all

TIMEOUT_MS = 1_000
t = time.ticks_ms()
while True:
  if sm.rx_fifo():
    while sm.rx_fifo():
      latestData = sm.get()
    print("Latest data = {}".format(latestData))
    t = time.ticks_ms()
  elif (time.ticks_ms() - t) >= TIMEOUT_MS:
    print("Timed-out")
    t = time.ticks_ms()
My reason for blocking was quite simply "why bother doing timings if what's using them isn't keeping up'. I did think about not blocking but couldn't figure out if there is any advantage either way, though I didn't spend long thinking about it.

horuable
Posts: 163
Joined: Sat Mar 06, 2021 12:35 am

Re: Speed measurement on a Triton router

Sun Aug 01, 2021 8:05 pm

Ok, somehow I didn't think about doing it that way. In this case, it's definitely the way to go. And yeah, the naming is less than intuitive...

I thought about counting every revolution because it shouldn't be too hard to achieve and I think having the most up-to-date reading is never a bad idea, and with 500 Hz signal Pico shouldn't have any problems with keeping up. On the other hand, I can see a potential problem with a first count after stopping and starting again, so maybe it's not that good of an idea after all. I guess it's for OP to decide what's best for his application.

hippy
Posts: 10530
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Speed measurement on a Triton router

Sun Aug 01, 2021 8:27 pm

The problem with 'development at a distance', plus not having the hardware, is one can theorise, surmise and propose, but nothing beats hands-on dong it, being able to see what issues are encountered which hadn't been considered.

That's another reason I prefer the 'get it working, no matter how badly, then improve and optimise' approach because it's well suited to that.

Only when an OP comes back with "That's great, but ..." can we tell how well we did, go back and figure out what was over-looked, less than ideal.

Luckily something like blocking or not blocking is a simple edit, easy to try.

What I actually quite enjoy is when someone comes back with "you know what you screwed-up there", because it means they got the help or push they were needing and are well on their way.

Quax
Posts: 26
Joined: Mon Jul 26, 2021 5:51 am

Re: Speed measurement on a Triton router

Mon Aug 02, 2021 11:50 am

Hello hippy, after chasing your last post through the Google translator, I am very insecure. I hope I have not left the impression of a know-it-all, on the contrary, I am extremely grateful that you are trying to help a newcomer. So if the impression of arrogance on my part should have arisen anywhere, I apologize in all form!
Horuable wrote that he tends towards your solution. I have to admit that I have not yet looked at this program because I understood your program even less than that of hourable. I have now printed out an overview of programmable PIOs and will (probably desperately and in vain) try to understand how your program works ...
Could you briefly describe how your program works? Why do you decrement the "X" variable in your program and why do you suggest incrementing it? What do you think of the change proposed by hourable with regard to standstill detection?

hippy
Posts: 10530
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Speed measurement on a Triton router

Mon Aug 02, 2021 2:27 pm

Quax wrote:
Mon Aug 02, 2021 11:50 am
Hello hippy, after chasing your last post through the Google translator, I am very insecure. I hope I have not left the impression of a know-it-all, on the contrary, I am extremely grateful that you are trying to help a newcomer.
And likewise, I apologise that my reply or its tone made you feel that way, thought that of you. I do not.

Your suggestion was perfectly acceptable. It is just that it does not work so well with MicroPython as shown. It is not your fault that you may not have realised that.
Quax wrote:
Mon Aug 02, 2021 11:50 am
Could you briefly describe how your program works? Why do you decrement the "X" variable in your program and why do you suggest incrementing it?
Incrementing would be the natural way to do things, would give an accurate and immediately meaningful count of how many ticks of the clock had gone by.

Unfortunately the PIO has only a limited number of instructions it can understand. There is an option to decrement an X or Y register, but nothing straightforward to increment one.

Hence the decision to decrement and then correct that decremented number so it appears as an incremented number after the sm.get() is executed.

An increment of X or Y can actually be performed by PIO ...

Code: Select all

          mov(x,invert(x))
          jmp(x_dec, "next")
          label("next")
          mov(x,invert(x))
But that uses more instructions and takes longer to execute, reduces timing resolution. So better to just decrement and correct the count later.
Quax wrote:
Mon Aug 02, 2021 11:50 am
What do you think of the change proposed by hourable with regard to standstill detection?
I am afraid I am not sure what change this relates to.

Quax
Posts: 26
Joined: Mon Jul 26, 2021 5:51 am

Re: Speed measurement on a Triton router

Mon Aug 02, 2021 3:30 pm

Hello hippy, please excuse me, I mixed it up. It was your program proposal for the timeout detection (standstill).
The two wait instructions "wait (0, pin, 0) and wait (1, pin, 1)" cause the measurement to be triggered each time a motor revolution, provided that first a low signal and then a high signal (as the actual Start of further routine)? Edge detection, so to speak?
Thanks also for pointing out why you are counting down in the jump instruction. I skipped that in the instruction description.

hippy
Posts: 10530
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Speed measurement on a Triton router

Mon Aug 02, 2021 8:04 pm

Quax wrote:
Mon Aug 02, 2021 3:30 pm
The two wait instructions "wait (0, pin, 0) and wait (1, pin, 1)" cause the measurement to be triggered each time a motor revolution, provided that first a low signal and then a high signal (as the actual Start of further routine)? Edge detection, so to speak?
Exactly that. The second will let things continue and do the counting when the input is high, the first ensures it was previously low before that high so it is edge detection.

Return to “MicroPython”