Spirograph emulator with Duet2

o_lampe

@mrehorstdmd said in Spirograph emulator with Duet2:

you periodically have to push it back toward the center of the table. That's going to be very difficult if the two pieces of glass are glued together and only a few mm apart

I already filled the glass-gap with 1/3 Soda and started to even out the layer. The small gap between ball and upper glass was actually helpful: I could attract it with a second magnet through the top and move it by hand. A separate comb/wiper would be better, but there's always a next time..

If things work out, I'll draw the first lines today, but only in the center area (~300x200mm) and this time I won't forget to take pictures

mrehorstdmd

@o_lampe Maybe you can build in a magnetic comb that sits between the glass sheets and move it with magnets from the top side when needed, and leave it along an unlit edge when it isn't needed.

o_lampe

A question about an exotic kinematic: @JoergS5
Would it be possible to add a rotary tool to a CoreXY frame?
The idea is to put the magnet on a 10cm arm rotating around the tool carrier, because
I want to reach areas outside of the current print envelope.
To achieve that, I was thinking of a postprocessor which moves the arm in 90° steps, depending on the direction I want to extend. (+/- Y or +/- X)
But it would be much cooler if it was an inbuild feature.

The other option would be quite expensive (for a side project). I'd have to build a frame much bigger than the glass, which means new alu-extrusion, linear rails and belts.

o_lampe

Another question is related to Meta commands/macros:
Is it possible to read out the total number of gcode files on the SD-card and run them randomly?
A macro call at the end of each gcode file would select the next...

JoergS5

@o_lampe said in Spirograph emulator with Duet2:

Would it be possible to add a rotary tool to a CoreXY frame?

The current RRF firmware calculates tools as being vertical, non rotating, non moving, describable with fixed XYZ offets (mesh compensation, baby stepping, tool changer depend on this linear offsets, e.g.).

To avoid this limitations, the tool itself can be divided into a part like a moving/rotating axis and a fixed endpoint which can be dimension zero. With robotic kinematics, you simply add this additional axis to the chain. Forward kinematics is easy to calculate, but inverse kinematics (calculation from world coorinates back to motor positions) can be complicated. It depends on the implementation and axis positions whether it's complicated or not.

If you design your tool as a spheric design, so that some axes cross in one point with the axes before, the inverse calculation is easier. When you have a prototype and description, we can solve it together.

o_lampe

@o_lampe said in Spirograph emulator with Duet2:

Another question is related to Meta commands/macros:

What I got so far:

I rename all the patterns with numbers
I add a subdirectory for wiper/eraser patterns
I choose the next pattern by a random generator and filter out nonexisting numbers with if exists
after each pattern, I call a random wiper pattern and vice versa

That way I don't have to know the exact number of existing patterns

o_lampe

I'm still pondering how to build the frame. It should not be much bigger than the glass plate and still reach (almost) everywhere.
The best kinematic option we already have is the delta: I could turn around the delta effector to show upwards and the three towers would act as table-feet.
I just have to find round glass plates and build a sandwich. (bottom plate could be dibond as @mrehorstdmd suggested)

<edit> looking for glass tables I stumbled across this round infinity table
How cool would that be in combination with a sandtable?!

mrehorstdmd

@o_lampe AFAIK, the Duet firmware doesn't have any provision for random number generation. I use macros, painstakingly composed, to play sequences of patterns. I'm thinking of writing a spreadsheet or maybe Perl script to create macro files by randomly selecting from a list of pattern files and a list of erase files.

Infinity tables only work when you can see the mirror at the bottom of the table. In a sand table, it's going to be covered by the sand, unless you limit the sand drawings to an area at the center of the table.

dc42

@mrehorstdmd see the 'random' function at https://docs.duet3d.com/en/User_manual/Reference/Gcode_meta_commands#functions.

o_lampe

@mrehorstdmd Good point. I thought the miracle behind the infinity trick is the semi-transparent top-mirror, but with sand at the bottom it won't work.
Glad I didn't order it

o_lampe

Here's a rough sketch of a SlimDelta which works upside down.
Motors and extrusion are mounted inline, which will free up the print-area.
I hope I can get away with NEMA14 motors (0.4Nm) because the effector + magnet weight is so low.
Long rods and narrow triangle will give me the biggest print area, accuracy is not important here. The magnet will drag the ball along, even with a few millimeters gap between.

mrehorstdmd

@dc42 The controller has no RTC, so what seeds the random function? If I set up a macro to randomly select and run gcode files from a list, will it give me a different file/sequence each time the controller is powered up, or will it give me the same pseudo random sequence of files each time? Thanks!

mrehorstdmd

@o_lampe I don't know that you gain much drawing area using a delta mechanism. I don't think you can draw any further than the towers, so you'll still have a wide, undrawn perimeter like what you get with a corexy or other rectangular mechanism. A lot of people make SCARA mechanism sand tables. With those the magnet is on the end of an arm that can reach very close to the edges of the table. The mechanism is located at the center of the table, so there's plenty of room for people's legs/feet if they are sitting around the table.

See: https://robdobson.com/2018/08/a-new-sandbot/

dc42

@mrehorstdmd said in Spirograph emulator with Duet2:

@dc42 The controller has no RTC, so what seeds the random function? If I set up a macro to randomly select and run gcode files from a list, will it give me a different file/sequence each time the controller is powered up, or will it give me the same pseudo random sequence of files each time? Thanks!

The 'random' function uses the hardware true random number generator if the MCU has one (which is currently the case for all Duet 3 main boards). If it doesn't have one then the generator is seeded by the system tick counter the first time it is called.

mrehorstdmd

@dc42 Will it work with the Duet2 Wifi board? I typically set up the controller to run a macro containing a sequence of patterns to run at power up. That way I don't need to have a UI or even to connect to the machine.

I am not familiar with the way tick counter works. If I use the random function to select files to run instead of a macro that contains a specific sequence, will it give me the same sequence each time I power up the board, or is there some variability in the power up timing that will result in a different seed when I use the random function after each power up? Thanks!

o_lampe

@mrehorstdmd I guess, the homing sequence is never the same, depending on the starting points of the axis'. When you call random afterwards, the seed will be different.

dc42

@mrehorstdmd the MCU in Duet 2 doesn't have a true random number generator so it will use the system tick counter as the seed. The tick counter increments at 120MHz once the processor clock has been set up. So even a small change in the timing of e.g. reading config.g from the SD card or homing the axes would change the seed. Let me know if you don't find it to be random, in which case I could look at using the CPU temperature to contribute to the seed too.

mrehorstdmd

@dc42 Thanks! I will try it out and see if I can get it working.

o_lampe

@mrehorstdmd A SCARA arm in the center would be nice, but I don't know if RRF supports the 360° working area? @dc42 @JoergS5 ?
alt text
The design is 7 years old, I wonder if there are improved designs available, a counterweight would be nice IMHO.

mrehorstdmd

@dc42 I'm having some trouble figuring out how to randomly select a file from the /gcodes/ folder. Do I have to put the files names in that folder in an array, or is there a way to declare the contents of the /gcodes/ folder as an array? I currently have about 200 gcode files stored in the /gcodes/ folder, and I add more files to it as I generate them.

I typically run a macro at the end of the config.g file, like this:

M98 P"/macros/macro01"

And that macro file looks like this (though much longer):

; file name: macro01
M98 P"/gcodes/wipe_03.gcode"
M98 P"/gcodes/file_04.gcode"
G04 S60
M98 P"/gcodes/wipe_01.gcode"
M98 P"/gcodes/file_02.gcode"
G04 S60
M98 P"/gcodes/wipe_02.gcode"
M98 P"/gcodes/file_06.gcode"
.
.
.

Should macro01 file look like this:

; file name: macro01
var myfile = {"file_01", "file_02", "file_03", "file_04", "file_05", "file_06"}
M98 P"/gcodes/^myfile[random 6]^.gcode"
G04 S60
M98 P"/gcodes/^myfile[random 6]^.gcode"
.
.
.

It seems like I'll quickly run out of line length if I try to put all 200 file names in the variable declaration.

I'll try to work out looping after I get random selection worked out...
Thanks!