I suppose it could be a neat little visual tool to introduce kids/people to the world of cnc routing, or lasing. For instance, it wouldn’t be too much work to create some tool paths of simple shapes, etc. then create a corresponding tool bar to select a shape and drag and drop onto the canvas. As soon as the shape is dropped, turn the spindle and run the tool path codes. I guess you could even go beyond simple shapes to more intricate carvings. Lots of possibilities.
3 Likes
Big file!
The mouse approach produces jagged lines. I’m going to look into how to increase the input area, so that it’ll be easier to write/draw/ (chatGPT suggested that I differentiate between the physical canvas and the onscreen canvas by introducing new variables for oncscreen size and scaling accordingly. Trying it out now). Simply zooming in messes up the pointer offset.
You are a hero! I think this can be a crowd pleaser for many schools, maker faires and maker spaces. Especially if this can be expanded into more complex drawing tools, vectors, raster import etc. All these would be amazing to do “on the go”. I think @Tokoloshe is hooked. I’m sorry for messing up your very nice thread on the beautiful plotter you made.
3 Likes
You’re very welcome. I love the tape measure! 
1 Like
Here is the upscaled screencanvas:
www.askevold.net/drawtest2.html
It worked! Haha, chatGPT doesn’t know what glue works best on glueing birch to acrylic, but they know how to rewrite javascript 
2 Likes
What you really want to do is dynamically size the canvas based on the size of the screen. You would also need to redo this after resize.
I was playing with this hoping to speed it up but didn’t make any meaningful difference. I changed the X and Y numbers to add .toFixed(1) so it wasn’t including position to 13 decimal places. Even changing G1 to G0 didn’t make much difference (which puts it at max feedrate).
Also, this could be converted to a WebUI v3 page extension pretty easily. This would allow for you to host it on the Jackpot and use the existing WebUI websocket. You could further remove custom config by reading $/axes/x/max_travel_mm and $/axes/y/max_travel_mm, assuming they have been set in config.yaml.
1 Like
I was thinking that it might help to create a constant called drawRes in the settings. That would represent the frequency of points that get sent to the plotter. As it stands, that value is 1 (every point). 2 would be every other point. 3 would be every third point… You would also need to initialize a counter variable, call it resCount = 0.
Then in the touchmove and mousemove functions, increase the counter by 1, and if it equals drawRes, send the code to the plotter and reset the resCount to 0. If it is less than drawRes, skip sending the code for that point to the plotter.
Be sure to reset the resCount to 0 in the functions where the pen gets lifted (mouseup and … I forget the touch one). You might also want to send the most recent point to the plotter in those functions as well just to make sure you end where the actual line on the canvas ends.
Try different values for drawRes to see what works best.
I don’t have time to try it now. Maybe tomorrow unless someone beats me to it.
Cheers
2 Likes
I was thinking something similar, except I was thinking of tracking the previous point that was moved to and only moving if it’s above a certain distance threshold. Actually, it might be best to combine this with what you said. If you’re drawing fast, you might want every point, but if drawing slow, it might make sense to skip some. Although, I’m not sure what triggers the move event to fire so maybe this is effectively equivalent.
Yeah, I think a distance threshold is a better approach in general. Case in point, when I first created this plot
it had around 140,000 points. The line segments (there are no actual curves in the g-code) became more and more visible as the radius grew. Makes sense - a circle with a 5mm diameter made up of 10 line segments pretty much looks like a circle, but a circle with a 500mm diameter will look like a decagon, because it is. In order to smooth out the curves, I increased the sampling by a factor of 10, and the new plot had 1.4 million points making the sharp edges barely noticeable. But even though the size of the g-code file increased by a factor of 1000%, the time it took to draw increased by less than 10%. Much of which could be accounted for by the increase in distance that the pen had to travel (it wasn’t cutting as many corners). My point is, simply decreasing the number of points sent to the plotter may not have a significant impact on drawing time. As I mentioned before, I believe that the biggest impact on speed would be to minimize the changes in direction that are inherent in the drawtest program. You can’t see them because they are so small, but fluidNC is seeing lots of 45 to 90 degree changes in direction (even if it’s only for 1mm), so I’m guessing it slows down to make the corner. This is just a theory of course, but if it is true, then both our approaches will help to decrease draw time, but the distance threshold should have less impact on the integrity of the plot, so I feel it would be a better approach.
Here is a visual… The top line represents what the plotter would do if it drew one continuous horizontal line that was the same thickness as the pen tip. The bottom line is the result of dragging my finger slowly across the canvas in the drawtest program. All those extra points where the line is twice as thick, are sent to the plotter, and I believe it is the directional changes up and down which has the greatest impact on speed.
3 Likes
Here is a new version of drawtest.html that will auto size the canvas based on screen size and orientation.
It also has a variable in the settings called distanceThreshold. This can be set to the distance (mm) that a point needs to exceed from the previously drawn point in order to be plotted. If the distance from the last point is less than this, the point is skipped. I did some quick tests drawing a circle and found the following:
distanceThreshold = 0 Every point is sent to the plotter
distanceThreshold = 1 Drawing time was reduced by 43%
distanceThreshold = 2 Drawing time was reduced by 57%
distanceThreshold = 3 Drawing time was reduced by 65%
Values above 3 had no further significant impact of drawing time.
drawtest_v2.zip (3.5 KB)
2 Likes
My Ratrig has Beacon Contact. Definitely recommended.
3 Likes
That is definitely quantization errors. I could imagine a complicated debounce algorithm. But a low pass filter would probably work better. It could be tricky to balance quick responses with less noise.
A simple choice of only using the new point when it is more than 1mm from the previous is a good LPF. But you could do sub-pixel resolution if you averaged out several samples.
Here is an idea: What if you computed the vector from the previously recorded point to each touch sample. The vectors have an angle and a magnitude. Once the magnitude was over some resolution, you would want to record a new point. The position of the new point would be the magnitude of the latest sample, but a weighted average of the angle of each previous sample. You wouldn’t want small vectors to affect the angle a lot, so you would want to remove those, or weigh them less in the average.
That should give you higher resolution than your samples in the angle, and work for any orientation of a line. Angle averaging has a few ugly corner cases (because 1 degree and 359 degrees average to zero).
3 Likes
I’m officially building one of these. I ordered the parts for the frame. Excited for the build and all the fun software things. My only currently planned deviations are size (24" paper) and using addressable RGBW LEDs with a WLED controller using my FluidNC usermod (which will need some more enhancements). Thanks for sharing all of this @Stoli
3 Likes
What speeds are you running comfortable at? My simple rod based plotter runs at 4200. I’m really curious to jump along with @jeyeager 
To be honest, other than this latest experiment with real time plotting, I haven’t spent much time trying to optimize the drawing speeds. I think it would depend quite bit on the pen being used. For the majority of the stuff I have drawn so far, I draw at 1500. And, I chose that because it was a pleasant speed to watch the thing draw at. Not too fast and not too slow. It is also nice and quiet. I’m sure I could speed it up some with the fine liner pens and quite a bit faster with larger felt tips. Not so sure with the ballpoints. Also, keep in mind that all the stuff I have drawn, even the raster images, are converted to SVG and then to gcode, so they don’t suffer from the speed problem that the "drawtest " program has. The max speed set in the fluidNC config is 9000, so that is the speed that can be used to reposition the pen between ups and downs. It handles that with no problem, but it can get a little loud though.
I really want to build this but don’t know if I have the patience for the ambiguity lol
I really want to build this but have no room for it! lol
It mounts on the wall! I understand every flat surface has stuff on it, but for sure you can take down some family photos and make room.
1 Like
And if you build it for 24 inch wide paper instead of 36, you only need about 9 square feet of wall space instead of around 16…
3 Likes