Minimum "on-time" for hal toggle pin
15 Jul 2023 17:50 #275520
by zdenek
Replied by zdenek on topic Minimum "on-time" for hal toggle pin
@rmu Indeed, you have to consider jitter (as you need to consider tolerances in every physical/real world case). When we say 1ms we really mean 1ms +/- epsilon, a jitter inherent to the system design. The ">" inequality sign implicitly covers that jitter. It is true that >=2T would be a safe bet, as would, e.g., >=7T be. My point was that >T && <2T would also suffice.
@beefy said : "If my thread ran every 1 millisecond, then would the hal signal being high for 3 milliseconds be reliable enough?"
I interpreted the question as "is there any special magic to be considered here, above and beyond the obvious?". And my answer is no, there is nothing special here, and common sense applies. If you want to check if your favorite 4:15 long song was being played on the radio on a given day, all you had to do was to turn the radio on and check every four minutes and you would not miss it. No need to check it more frequently.
When it comes to sampling signals in general there indeed are properties to be considered and possibly concerned about. There is latency (delay) due to the discrete nature of sampling (1ms here), there is hardware synchronizer latency due to the sampler being asynchronous with respect to its input (not applicable here), there is sampling with the intent to reconstruct the sampled signal where >2f is required per Shannon-Nyquist (also not applicable here as we just want a boolean status), but I can't think of anything that would need to be considered here given @beefy question.
All that said, pragmatically and defensively speaking, you do have to be aware of the jitter. Linuxcnc is not a hard real time system -- you could see an occasional surprising departure from the 1ms nominal time. Consequently, a 1.2T pulse would be statistically better than a 1.1T pulse and of course a 2T pulse would improve the chances further, but so would 2.5T and my point was that the 2 factor appeared rather arbitrary. More importantly, I wanted to observe that I don't see anything algorithmic or design-based implying [precisely] 2 over any other factor greater than 1.
If I misinterpreted the question, and @beefy was concerned about the soft real time nature of Linuxcnc and the unpredictable jitter, then I'd say his original suggestion for a 3ms pulse was as good as any.
Finally, not knowing how the Qtplasmac module exactly fits in, and what "my thread" really means leaves even more room for an interesting discussion
.
Cheers
@beefy said : "If my thread ran every 1 millisecond, then would the hal signal being high for 3 milliseconds be reliable enough?"
I interpreted the question as "is there any special magic to be considered here, above and beyond the obvious?". And my answer is no, there is nothing special here, and common sense applies. If you want to check if your favorite 4:15 long song was being played on the radio on a given day, all you had to do was to turn the radio on and check every four minutes and you would not miss it. No need to check it more frequently.
When it comes to sampling signals in general there indeed are properties to be considered and possibly concerned about. There is latency (delay) due to the discrete nature of sampling (1ms here), there is hardware synchronizer latency due to the sampler being asynchronous with respect to its input (not applicable here), there is sampling with the intent to reconstruct the sampled signal where >2f is required per Shannon-Nyquist (also not applicable here as we just want a boolean status), but I can't think of anything that would need to be considered here given @beefy question.
All that said, pragmatically and defensively speaking, you do have to be aware of the jitter. Linuxcnc is not a hard real time system -- you could see an occasional surprising departure from the 1ms nominal time. Consequently, a 1.2T pulse would be statistically better than a 1.1T pulse and of course a 2T pulse would improve the chances further, but so would 2.5T and my point was that the 2 factor appeared rather arbitrary. More importantly, I wanted to observe that I don't see anything algorithmic or design-based implying [precisely] 2 over any other factor greater than 1.
If I misinterpreted the question, and @beefy was concerned about the soft real time nature of Linuxcnc and the unpredictable jitter, then I'd say his original suggestion for a 3ms pulse was as good as any.
Finally, not knowing how the Qtplasmac module exactly fits in, and what "my thread" really means leaves even more room for an interesting discussion
.Cheers
Please Log in or Create an account to join the conversation.
Time to create page: 0.232 seconds