Page 1 of 1
RevPiModIO cycleloop seems to skip cycles on a regular basis
Posted: 05 Jul 2024, 11:15
by florian.schulte
Hello,
I have an application where I want to measure an incoming digital signal and check if it matches what I expect. My setup is capable of a cycletime of 5 ms, but my signal can have durations of only 20 ms. I measure in a cycleloop, and allow an error of 10 ms, so I should not detect errors where there are no errors in my signal. BUT I do detect errors, while my oszilloscope tells me there was no error in the signal. A little bit of digging broke it down to this problem:
Code: Select all
rpi = revpimodio2.RevPiModIO(True)
CT = 5
SL = 1.05
actual_time = time.perf_counter()
def main(ct):
global actual_time
rpi.io.DO_3.value = not rpi.io.DO_3.value # type: ignore
new_time = time.perf_counter()
if abs(new_time - actual_time) > CT * SL:
print("Failed")
actual_time = new_time
rpi.cycleloop(main, cycletime=CT)
This pice of code should toggle my signal every 5 ms, but my oszilloscope tells me, that, on a regular basis, the revpi skipps a cycle. With a cycletime of 5 ms, every third high Signal has a length of 10 ms:
- error of revpi output
This error shifts with changing cycletimes, so a 10ms Signal is sent for example every 5th toggle time, but it barely vanishes. I assume, that this phenomenon occures on reads as well, so my measurement has a possible error of 3 cycle times.
Why does this happen, and is there a way to avoid this?
Re: RevPiModIO cycleloop seems to skip cycles on a regular basis
Posted: 08 Jul 2024, 13:38
by dirk
Hi florian.schulte I thought about it a bit and couldn't really make sense of it at first. However, it becomes clear when you look at things from the outside - it's down to the system behaviour. There's a good article here that shows how analogue measurements can be carried out with the RevPi:
Measuring analog data with the RevPi AIO module
I know you are using a digital signal, but the article is generally valid.
What can you do now? Make sure that you adapt the steps in this article step-by-step to your system.
Re: RevPiModIO cycleloop seems to skip cycles on a regular basis
Posted: 08 Jul 2024, 15:27
by florian.schulte
Hi dirk, thank you for your reply. I'm not quite sure what you are referencing. I think, the Nyquist-Shannon sampling theorem doesn't apply in this case, at least not for sending a signal (but I think it doesn't apply for measuring the signal either, syncronous sending and measuring should be able to reproduce the digital signal, assuming there where no measurment errors or transmission errors).
So do you mean, it is simply possible to lose one cycle? And if that's what you ment, is it a software problem or a hardware problem?
(Because my first guess was, that the piControl process that updates the process image and the revpymodio cycleloop don't run in sync, so might be possible to miss a cycle there)
Re: RevPiModIO cycleloop seems to skip cycles on a regular basis
Posted: 11 Jul 2024, 11:13
by dirk
Hello florian.schulte, okay, that article does not point it perfectly out. But the last sentence points to it - the cycle loops of the process image and the RevPiModIO program in user space don't run in sync. So back to that article, there is the PiBridge cycle that you can read out on your system. I.e.:
Code: Select all
pi@RevPi39627:~ $ piTest -1 -r RevPiIOCycle
1 Byte-Value of RevPiIOCycle: 3 dez (=03 hex)
If it is 3, the cycle time equals 3.9 ms in the worst case. But another thing to have in mind is that you might lose one cycle. Thus, the worst case is 2ยท4ms = 8ms. So this is probably the reason for the error which you then detect in the oscilloscope.
Ah, and maybe the Nyquist theorem is, in fact, relevant.
Nyquist says that you need to sample at least double the frequency to restore the original signal.
In this example, the signal which can be restored from a frequency of 2/(8MS) = 1/(4MS) = 250 Hz.
But your application involves measurement and comparing the signals, right? So if you are measuring incoming data that has to be written into the process image then you have to add this cycle times on top of the previous calculation.
So maybe those really theoretical aspects are the key to understand the system parameters you need to implement your project.