Spirograph emulator with Duet2

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.

Another idea- rename all the files in the gcodes folder with simple numeric names:
1.gcode, 2.gcode.... 212.gcode

Then in the macro file, select a random pattern file like this:

M98 P"/gcodes/^{random(212)}^.gcode"

Sorry if this stuff is too basic. I've been away from programming for a looooong time.

o_lampe

@mrehorstdmd said in Spirograph emulator with Duet2:

M98 P"/gcodes/^{random(212)}^.gcode"

Basically, that's what I'd try too.
But I'd check, if the file (still) exists before I call M98. Unless you only put files in the gcode directory after you tested it. It would be a PITA to e.g. rename files 123-212 , just because file 122 turned out to be problematic or ugly or boring.

Alternatively you could edit the unwanted file and only leave the end code. The worst that can happen is running two wipe-file in a row.