Usleep question or similar for my M19 orient compo
this is now my 2nd component. I was tired to spend more time to get the M19 to work using all the configs simply not working. I have only 1 inductive switch with one ping per revolution it seems that all that configs use encooder with idex reset so my solution is an simple component where i calculate the ms to wait after passing the ping to get the desired angle and then i set is enabaled an M19 command in 2.6-pre2 is happy.
But i thought usleep is simply waiing x ms and proceed i get compile errors
so my question what do i do wrong or any better idea ?
thx thomas
Please Log in or Create an account to join the conversation.
Basically you cannot use userspace functions in a realtime component.
The way I have used to time actions in the past, is to set a counter and increment it each time the component is polled.
Another way is to use something similar to the timedelay component.
The main thing is that any delay must be non blocking and just return if the figure has not reached that desired.
regards
Please Log in or Create an account to join the conversation.
oh that is now clear
So in your experience
is it better to have an userspace component (the M19 has to be done anyway where all axis are stop and spindle as well )
but it has to react fast on that pin (thats why i choosed realtime )
i am very well aware of multi tasking systems so i really want to give back cpu time ,..
could you please advise me the better route ,..
would be nice
thx
thomas
Please Log in or Create an account to join the conversation.
is it better to have an userspace component (the M19 has to be done anyway where all axis are stop and spindle as well )
but it has to react fast on that pin (thats why i choosed realtime )
Entirely depends upon what elapsed time periods we are dealing with (ie what speed the spindle is rotating at and the smallest angle you are likely to want to calculate)
If everything else is stopped, you are really just competing with the polling of Axis to refresh its state and any other components that operate in the background
(always assuming you are not watching movies on another terminal or compiling a kernel
![:laugh: :laugh:](/media/kunena/emoticons/laughing.png)
A userspace component would be possible if the period between trigger and reaching required angle is long enough and if the trigger itself is long enough.
For a realtime component, have a look at linuxcnc.org/docs/html/hal/comp.html#_implicit_parameters for fperiod, which is what timedelay uses
You will need to use fp, so need to attach to the servo thread not base thread, but you can use it in a rt component for calculating elapsed time ( see the source of timedelay)
regards
Please Log in or Create an account to join the conversation.
You will need to use fp, so need to attach to the servo thread not base thread
I believe that Floating Point is now allowed in the Base Thread, at least in the dev versions:
git.linuxcnc.org/gitweb?p=linuxcnc.git;a...88d3017fc841e5acf503
Please Log in or Create an account to join the conversation.
thank you so much for the info
but beside the source where would i found that info ?
i have now a semi working solution
i added the solution as file and it works in the servor therad ,..
i only have the problem
that fperiod (which i used first ) or period dont have a for me predictable behaviour ,..
so i tried to "understand" the timedelay and timedelta
which works with an rtapi_gettime_
probably rtapi_get_clocks is a solution for my issue but how many nanoseconds are clocks ?
in my example it is easy i turn the spindle with 150 rpm which is 2.5 revolutions / second
means 900 degrees per second so
(1/900) * angle should give me the time i have to wait till the spindle is there
if i have a formula for clocks i am also happy
thx thomas
Please Log in or Create an account to join the conversation.
.....probably rtapi_get_clocks is a solution for my issue but how many nanoseconds are clocks ?
I only know what I have read here
www.linuxcnc.org/docs/devel/html/man/man...t_clocks.3rtapi.html
From the formula given to calculate where cpu_khz is known, the clocks are going to be different in every computer and based upon its processor frequency.
You can probably work it out for your computer but it will not be portable unless the figure can be fetched with cpu_khz within the component.
As you say, it seems like the most accurate method, if the exact period is crucial.
All my timing routines in components to date have been for periods which allow other things to complete, waiting for a hydraulic ram to extend, a relay to close etc.
As such I just needed a rough figure that allowed enough time and this could easily achieved with counters or using fperiod, so I have managed to sidestep this issue.
![:laugh: :laugh:](/media/kunena/emoticons/laughing.png)
regards
Please Log in or Create an account to join the conversation.
From the formula given to calculate where cpu_khz is known, the clocks are going to be different in every computer and based upon its processor frequency.
It almost certainly makes more sense to use rtapi_get_time, nothing mechanical happens in nanoseconds.
A typical "wait" snippet would be a state machine such as
unsigned long long timestamp;
switch (component_state){
....
case 11:
<some code>
if (condition to start waiting) {
timestamp = rtapi_get_time();
component_state = 12; }
case 12:
if (rtapi_get_time() - timestamp > 1e9LL * wait_time_s ){
component_state = 13;
}
case 13:
<more code>
Please Log in or Create an account to join the conversation.