You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a possible time-and-buffer saving tool, it might be helpful to add certain canned routines-- tiny macros, so to speak, that might be able to perform some higher level functions within CNCserver.
Typical CNCserver commands are of the form (in pseudocode, not actual API operations):
pen: Go to (x,y)
pen: down
tool: get water
tool: get color1
These operations typically result in a motor movement, possibly with a subsequence of operations that are performed. For example, "get color1" will perform "pen up, move to position, pen down, wiggle, pen up", using a lookup table to find the required position. However, a considerable time and memory savings might be possible by adding some higher level commands. For example, a drawing that makes 10,000 circles would go much faster if it could send 10,000 command of the form "draw a circle" than if it had to specify the polygon segments that make up each circle.
I propose adding a new category of "canned" routines to handle things of this sort. It could perhaps have the command form PUT /v1/canned/{routinename}. These canned routines should be essentially independent of the tool being used, so that they can be used with any type of tool, in any context-- whether the pen is up or down, and whether it is a brush or a pencil.
Potential examples could include:
circle(radius) -- draw a circle, centered at the pen's current (x,y) value, with the given radius. A potential challenge is in determining the number of vertices/segments that should be used to draw the circle. It could default (say) to 3 + floor(radius/5), or some other "reasonable" formula. It could also use a minimum/maximum segment length specified some other way, perhaps as part of the tool specification ("typical segment length for canned routines").
circle(radius, number of vertices) -- to explicitly set the number of vertices
ellipse(axis1, axis2). Draw an ellipse, centered at the pen's current (x,y) value. The axes are distances (either could be the major or minor axis).
ellipse(axis1, axis2, angle), where the axes are distances, and the angle is specified between the X axis and the ellipse to be drawn
rectangle(length1,length2)
etc (arcs? filled rectangles? spirals?)
This new category may not be the best approach -- I am 100% open to alternate suggestions of better ways to approach this.
The text was updated successfully, but these errors were encountered:
Adding the capability for CNCserver to handle these little canned routines might also make for more elegant handling of things like doing the wiggle while getting paint-- it could trace out neat spirals or ellipses in the paint dish instead.
As a possible time-and-buffer saving tool, it might be helpful to add certain canned routines-- tiny macros, so to speak, that might be able to perform some higher level functions within CNCserver.
Typical CNCserver commands are of the form (in pseudocode, not actual API operations):
These operations typically result in a motor movement, possibly with a subsequence of operations that are performed. For example, "get color1" will perform "pen up, move to position, pen down, wiggle, pen up", using a lookup table to find the required position. However, a considerable time and memory savings might be possible by adding some higher level commands. For example, a drawing that makes 10,000 circles would go much faster if it could send 10,000 command of the form "draw a circle" than if it had to specify the polygon segments that make up each circle.
I propose adding a new category of "canned" routines to handle things of this sort. It could perhaps have the command form
PUT /v1/canned/{routinename}
. These canned routines should be essentially independent of the tool being used, so that they can be used with any type of tool, in any context-- whether the pen is up or down, and whether it is a brush or a pencil.Potential examples could include:
This new category may not be the best approach -- I am 100% open to alternate suggestions of better ways to approach this.
The text was updated successfully, but these errors were encountered: