Thoughts on avr event scheduling - Revision history

Admin: Admin moved page Thoughs on avr event scheduling to Thoughts on avr event scheduling: mispelled

2017-03-22T15:38:55Z

Admin moved page Thoughs on avr event scheduling to Thoughts on avr event scheduling: mispelled

← Older revision	Revision as of 08:38, 22 March 2017
(No difference)

129.42.161.36 at 00:35, 30 January 2009

2009-01-30T00:35:56Z

@@ Line 41: / Line 41: @@
   link to next move
   dwell time
 == Event Queue ==
@@ Line 48: / Line 55: @@
   id
   link to next event
   type = 1 step
@@ Line 67: / Line 75: @@
   id
   link to next event
-  move control block to run execute in the future
+ number of mcbs in this event

129.42.161.36 at 00:23, 30 January 2009

2009-01-30T00:23:38Z

← Older revision		Revision as of 17:23, 29 January 2009
Line 22:		Line 22:
	When somebody schedules a new event, we determine if the new event should fire after or before the first one in our current list. If before, we put it in the list before the first item and reset the interrupt trigger time to our new event's time. If after, we put it in the list in the right spot and call it good.		When somebody schedules a new event, we determine if the new event should fire after or before the first one in our current list. If before, we put it in the list before the first item and reset the interrupt trigger time to our new event's time. If after, we put it in the list in the right spot and call it good.

	Scheduling an event and the checking to see if we need to run an event need to occur under an event list lock, so we don't mess up our event list or the timer. ~~Not sure how we can safely do that on the AVR~~ yet, ~~but there should be a way~~.		Scheduling an event and the checking to see if we need to run an event need to occur under an event list lock, so we don't mess up our event list or the timer. Just use a spin lock probably, and enable/disable interrupts around our check and set.

			== Move List ==
			move list lock, next move ptr, next available id, plus list of move control blocks, each containing:
			type = 1(move)
			id
			status 0 not yet active, 1 in progress, 2 complete, at target, 3 complete, not at target
			link to next move
			x,y,z endstop/position status (0, ok, 1 max endstop, 2 min endstop, 3 max steps, 4 min steps)
			x,y,z target
			x,y,z velocity (current)
			x,y,z acceleration
			link to next move

			type = 2(dwell)
			id
			status 0 not yet active, 1 in progress, 2 completed.
			link to next move
			dwell time

			== Event Queue ==
			event queue lock, next event ptr, next available id, plus list of event control blocks currently scheduled
			type = 0 nop
			time to fire
			id
			link to next event

			type = 1 step
			time to fire
			id
			link to next event
			axis
			move control block ptr

			type = 2 run
			time to fire
			id
			link to next event
			function ptr to call (of type (void)(void*))
			ptr to pass to function when run

			type = 3 move
			time to fire
			id
			link to next event
			move control block to run execute in the future

Admin: New page: For my reprap playground firmware, I need a better way to schedule events. This will enable me to do g-code shorthand movement calls. The general form will be int moveVect(dx, dy, dz, r...

2009-01-29T06:49:43Z

New page: For my reprap playground firmware, I need a better way to schedule events. This will enable me to do g-code shorthand movement calls. The general form will be int moveVect(dx, dy, dz, r...

New page

For my reprap playground firmware, I need a better way to schedule events. This will enable me to do g-code shorthand movement calls. The general form will be
int moveVect(dx, dy, dz, rampUpTime, initialSpeed, finalSpeed, rampDownTime)
dx, dy, dz is the motion vector relative to current position, given in mm. rampUpTime and rampDownTime are given in seconds, and initialSpeed/finalSpeed are given in mm/s. moveVect returns 0 if we were able to move all the way to the target location. It returns 1 if we could not move all the way there because we hit an endstop. It returns 2 if we could not move all the way there because we think we would have hit another edge (no endstop).

To help us, we need to have steps per mm numbers for each axis (qx, qy, qz). We also should have a stepping interval time (qt). This is how long to actually have the motor coil energized. This should either be small enough to run during the event, or large enough that a new event to de-energize can be scheduled and run.

As we run through the moveVect() we determine a current speed by linearizing from 0 to initialSpeed over the rampUpTime interval, then linearizing to the finalSpeed over a calculated time it will take us to move in toto (could be tough..??), and finally linearizing back down to 0 over rampDownTime. After getting the current speed (s), we find out velocity vector (v) by normalizing the motion vector and multiplying it by the speed.
dh = sqrt(dx^2 + dy^2 + dz^2)
v = (dx*s/dh, dy*s/dh, dz*s/dh)

The next step events should be scheduled then at times in the future given by
1/(vi*qi) - qt
for each axis. This event simply steps the given axis by toggling the step line for qt seconds.

Each step event needs an axis and a direction. Associated with each move is a move control block, containing velocity vector information, acceleration vector information, and target location data, as well as info about if we stopped, and why.
At each event, we check endstops and position to determine if we have to stop, otherwise, we step, adjust that axis's velecity information using the acceleration information for that axis, and schedule the next event for that axis.

We can chain moves together in a list, and when one move is finished (all axis event chains have ceased, or we are on the last one), we pull up the next move control block and trigger its event chains for each axis.

We'll need to use one of the chip's timers for our interrupt, and the interrupt should look at the next event in the event list, and if its timer has expired or will expire, we execute it and remove it from the list. We then look at the next event in the list. If its timer has now expired, we execute that one too. We keep doing this until we have no more events or we find one that needs to execute in the future. We set our interrupt for that future time and exit.

When somebody schedules a new event, we determine if the new event should fire after or before the first one in our current list. If before, we put it in the list before the first item and reset the interrupt trigger time to our new event's time. If after, we put it in the list in the right spot and call it good.

Scheduling an event and the checking to see if we need to run an event need to occur under an event list lock, so we don't mess up our event list or the timer. Not sure how we can safely do that on the AVR yet, but there should be a way.