Minimum "on-time" for hal toggle pin

More
3 years 3 months ago - 3 years 3 months ago #275494 by beefy
Hi Rod,

nothing motion related or real time with what I'm doing. It's just hooking up all the Qtplasmac external hal pins to the outside world (my pendant).
All signals are coming from a microcontroller so I'll just make the pulse time as long as is needed to guarantee the servo thread and Qtplasmac picks it up.
I can really lengthen the pulse duration if necessary.

@zdenek
I think Rod is saying the servo period time of Qtplasmac may be longer. I know what my servo period is for my custom component but I'm not sure how long the servo period(s) for Qtplasmac external hal pins are. It's possible they may be longer.
Last edit: 3 years 3 months ago by beefy.

Please Log in or Create an account to join the conversation.

More
3 years 3 months ago #275496 by rodw

@rodw Do you believe that a 1 ms periodic thread will not see a 1.5 ms wide pulse?
I don't think it can be guaranteed but I've done no testing.

@Beefy, there is no such thing as a timing thread on the real time side. It just gets done when it gets done.
The 7i73 you have on the either hand is real time.
But having said that, if ts just a pendant, it won't matter

Please Log in or Create an account to join the conversation.

More
3 years 3 months ago #275498 by rmu

@rodw Do you believe that a 1 ms periodic thread will not see a 1.5 ms wide pulse?
you have to allow for some jitter on the µC and the PC side, >=2 periods is the safe bet. 

Please Log in or Create an account to join the conversation.

More
3 years 3 months ago #275520 by zdenek
@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

Please Log in or Create an account to join the conversation.

More
3 years 3 months ago #275539 by PCW

Why > 2 and not > 1 ?
 
>1 gives no margin for jitter
 
I chose 2 based on my experience with our Ethernet connected devices
(and the default timeout values used)

Please Log in or Create an account to join the conversation.

More
3 years 3 months ago #275628 by rmu

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.
 
I think the "Unexpected realtime delay" warning is issued if jitter of >1T occurs, i.e. an interval >2T, so from that POV it makes sense to use 2T, further increasing the period length won't buy you much -- you shouldn't run a machine where "Unexpected realtime delay" warnings are occuring. 
The following user(s) said Thank You: rodw

Please Log in or Create an account to join the conversation.

Time to create page: 0.364 seconds
Powered by Kunena Forum