Pause/Resume

[Leonardo Romor]

As  pause we mean a quick deceleration that doesn't violate machine constraints avoiding any steps loss.

What I think we could do, since we should follow the profiled path for decelerating and not randomly moving in a direction to just stop.

Would be to change the pru code so that we can force a deceleration from whatever accel/deve/travel we are doing to consume any possibile step as deceleration for the next slots.

what do you think?

-l

[Henner Zeller]

On 8 July 2016 at 07:47, Leonardo Romor <leonard...@gmail.com> wrote:
> As pause we mean a quick deceleration that doesn't violate machine
> constraints avoiding any steps loss.

Yep. Essentially so that it is possible to pick up afterwards. It is
meant if someone say opens the CNC machine door to inspect the part.
It does not need to be 'immediately', I think it is ok if it takes a
couple of seconds until we get there.

> What I think we could do, since we should follow the profiled path for
> decelerating and not randomly moving in a direction to just stop.
> Would be to change the pru code so that we can force a deceleration from
> whatever accel/deve/travel we are doing to consume any possibile step as
> deceleration for the next slots.

I think there is no need to touch the PRU or have the PRU do something
special. The PRU can't do the work necessary of the 'pause/resume'
thing, because it is a little more complicated than stoping the
current path in the tracks: we might need multiple deceleration
segments to get there (we only can do 64k steps per segment, and if we
are very fast currently, we might need multiple segments to slow down;
something to calculate for the host CPU).

What we need to do is from the host side to look at the segments in
the queue that have not been consumed by the PRU yet, and just replace
the one after the current one with something that decelerates (along
the path it currently is) to zero; maybe these are multiple segments
we need to enqueue actually if the current speed is very fast.

There can be a race condition if the PRU is faster executing the
previous segment than we are able to fully replace the next segment,
so that needs some more detailed thought. But in general, all the
complexity is in the host-side, with the only changes needed for the
PRU to deal with the race condition thing mentioned above.

Anyway, after that, we know exactly where we are, and know exactly
what to do to continue in our track (with some re-calculation, e.g. we
need to speed up again etc.). Also, we can allow the user to jog
around while they are paused (for instance, because they want to
inspect the work-piece without the spindle in the way, want to vacuum
etc.), and then go back to the original position before continuing.

-h

>
>
> what do you think?
>
> -l
>

> --
> You received this message because you are subscribed to the Google Groups
> "beagleg-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleg-dev...@googlegroups.com.
> To post to this group, send email to beagl...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleg-dev/0d0a7f61-1c00-4d7c-91cf-490e95956106%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Leonardo Romor]

Il giorno lunedì 11 luglio 2016 18:19:55 UTC+2, Henner Zeller ha scritto:

On 8 July 2016 at 07:47, Leonardo Romor <leonard...@gmail.com> wrote:
> As  pause we mean a quick deceleration that doesn't violate machine
> constraints avoiding any steps loss.

Yep. Essentially so that it is possible to pick up afterwards. It is
meant if someone say opens the CNC machine door to inspect the part.
It does not need to be 'immediately', I think it is ok if it takes a
couple of seconds until we get there.  

> What I think we could do, since we should follow the profiled path for
> decelerating and not randomly moving in a direction to just stop.
> Would be to change the pru code so that we can force a deceleration from
> whatever accel/deve/travel we are doing to consume any possibile step as
> deceleration for the next slots.

I think there is no need to touch the PRU or have the PRU do something
special. The PRU can't do the work necessary of the 'pause/resume'
thing, because it is a little more complicated than stoping the
current path in the tracks: we might need multiple deceleration
segments to get there (we only can do 64k steps per segment, and if we
are very fast currently, we might need multiple segments to slow down;
something to calculate for the host CPU).

Ok, I think you are right if it's a couple of seconds, but as you mentioned, since we have

to wait (in the worst case scenario) a whole segment to finish, this could also be a very slow one, say we are moving 
with a machine that is configured with 200 steps/mm and we are engraving something at a very low speed such as 1 mm/s 

this should take up to 5 minutes before it stops (halved if 64k are loops and not steps)? Well in case we could reduce the slot max steps limit.

 

What we need to do is from the host side to look at the segments in
the queue that have not been consumed by the PRU yet, and just replace
the one after the current one with something that decelerates (along
the path it currently is) to zero; maybe these are multiple segments
we need to enqueue actually if the current speed is very fast.

There can be a race condition if the PRU is faster executing the
previous segment than we are able to fully replace the next segment,
so that needs some more detailed thought. But in general, all the
complexity is in the host-side, with the only changes needed for the
PRU to deal with the race condition thing mentioned above.

 

This could have different results based on the load of the cpu (as also other things), since it's not a realtime process, 

the circles are working fine, but there should be a protection that slows down the machine in case the cpu load is too high

and the host can't keep up on pushing segments, the machine could start trashing and losing steps.

 

Anyway, after that, we know exactly where we are, and know exactly
what to do to continue in our track (with some re-calculation, e.g. we
need to speed up again etc.). Also, we can allow the user to jog
around while they are paused (for instance, because they want to
inspect the work-piece without the spindle in the way, want to vacuum
etc.), and then go back to the original position before continuing.

-h

Tell me what you think about this:
set a bit in the pru dram that starts the pause process in the next delay calculation. The pause process could be implemented in the following way:

pause pin is on -> calculate delay is just decel so any loop of accel travel decel is consumed in this order, this is done until the index is 0, if the index at the end of the slot is not zero, we pass to the next slot.
Through multiple slots, the series index, and the actual delay should be conserved as starting values of the new slot. the only thing to be kept of a new slot should be the number of steps and the fractions.
To resume, we could do two things:

• the host re-evaluate the slots, since all the information is stored in the shadow queue. (much easier I guess)
  
• we are able to evaluate inside the pru the number of steps required to reach back the required speed at that point. 

Does it make sense?

-l

>
>
> what do you think?
>
> -l
>
> --
> You received this message because you are subscribed to the Google Groups
> "beagleg-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to beagleg-dev+unsubscribe@googlegroups.com.

[Leonardo Romor]

Hello everyone!

this is a proof of concept of a doable pause-resume, tell me if you think that we could keep working in this way or if you find any troubles/issues or logical errors.

here is the pull request:

https://github.com/hzeller/beagleg/pull/18

[Leonardo Romor]

Hello Everyone, 

I made a branch that provides a basic pause-resume functionality plus a speed control by using a client outside beagleg,

to compile the client, remember to run "make pause-client". 

If you want, you can plug an analog device (e.g. a potentiometer) and use it with ./pause-client -a <analog number> and have fun with the speed control.

I made also a small python script to generate some convenience plots of the speed and accel using the pause client.
I will wait for your feedback