SBC mode on non-pi's

Phaedrux

The Pi is probably the easiest to get going, but other SBCs are potentially usable.

https://docs.duet3d.com/en/User_manual/Machine_configuration/SBC_setup

Do you have a particular alternative in mind?

jay_s_uk

@Mentaluproar we have instructions for running DSF on armbian here https://teamgloomy.github.io/dsf_on_armbian.html

Mentaluproar

@Phaedrux I have a rock64, a pair of old pcduino4nanos, a pi 2 and 3 (but I suspect they have shorts somewhere) and a pi 4 I'd rather not use for this.

Phaedrux

Of that list the Pi4 is probably the ideal candidate. The Pi3 would be second. Pi2 a bit too slow.

As for the others, I'm not familiar, but if they will run armbian and are as fast or faster than a Pi3, give Jays link a try.

Mentaluproar

@Phaedrux why does it have to be so powerful? it's just hosting a web server and streaming data to the control board. I would rather not use it in face but the uploads on wifi are unstable, slow, and only work if the card has few or zero jobs on it.

edit: I have the pi4 set aside for tinkering with. The 2 and 3 are indeed shorting and the nanos are closer to the pi 2 in speed. The rock64 has a damaged power port and I don't want to hack up the gpio cable to feed it that way.

So I found the le potato on amazon is available and has not been price gouged like the pis. Looks like that and Armbian will be my route. Thanks

Phaedrux

@Mentaluproar said in SBC mode on non-pi's:

le potato

Let us know how it goes.

o_lampe

@jay_s_uk said in SBC mode on non-pi's:

@Mentaluproar we have instructions for running DSF on armbian here https://teamgloomy.github.io/dsf_on_armbian.html

I went through the SBC pages again and still wondering why do people go the SBC route? With a RasPi setup it's straightforward, but I still see no advantage yet.
With armbians, I'm glad you wrote up a way to make it work, but it's quite cumbersome to do.

Will RRF3.5 benefit more from SBCs?

achrn

@o_lampe Doing things the printer board can't do itself.

I have SBC on my delta because it runs a weighing filament spool holder and controls some status lights. There may well be other ways to do it (status lights via daemon.g for example) but having the Pi with access to the object model makes those things reasonably straightforward.

I have a sand table that runs a Fly E3 Pro without an attached SBC. It uses a polar mechanism driven by RRF that thinks it's driving a cartesian kinematics with a long Y-axis (+/- 3,600,000 units, being 10,000 revolutions of 360 degrees) because although mechanically it's a genuinely continuous rotation axis, in my application a move from position 0 degrees to a position of (say) 370 degrees is different to a position of 10 degrees. Although most moves are segmented to fairly short pieces, it's sometimes useful to do a long move and on occasion a > 360 degrees one.

I have preprocessing routines that translate cartesian gcode or radians polar https://sisyphus-industries.com/ track files or dxf files (in which case it ignores everything but the polylines within) or perl scripts using a turtle-graphics-like library into looks-like-cartesian-really-degrees-polar gcode files which the table mechansim actually 'prints'. Not only does the conversion need computation, the computation needs to know some stuff about the machine status (like the starting position of the printhead). Currently I use a remote Pi that uses the https://github.com/Duet3D/RepRapFirmware/wiki/HTTP-requests functionality (e.g. get http://$ipaddr/rr_model?key=move.axes[0].userPosition but it would be easier with a properly attached Pi.

Next, I'm trying to synchronise animations across about 180 WS2811 LEDs to that as it prints, and that would be very much easier if it had the Pi tightly attached.

So from my point of view, if I was just using it as a printer with the out-of-the-box functionality, the Pi (or other SBC) doesn't add much (if anything), but extending it to do things the board can't do is / would be easier with a more general purpose computer tightly integrated. Obviously the sand table actually demonstrates that you don't need an attached SBC, but I think it would be better if it had one (I think the board I'm using can't use one, though I'm not 100% on that - some of the 3rd party boards can). Also obviously, it's a fairly niche application of RRF.

Just for interest (and showing off):

A dxf I drew (8 polylines, up to about a thousand vertices per polyline, expands to about 48,000 lines of gcode):

A simple turtle graphics, from a four-line for loop (a repeated move to point turning through a degrees as you do so) which the Pi expands to about 16,000 lines of gcode. This uses a polar position, but the library has both polar and cartesian functions.

for ($n=0; $n<$segs*300/$spc; ++$n) {
	$a=$a+360/$segs;
	$r=$r-$spc/$segs;
	tg::g1pa($r,$a,-2*360/$segs);
}

Mentaluproar

@achrn You're the guy behind Sisyphus? I built a large rectangular coreXY coffee table that was inspired by that, but I never finished. At the moment, I just solved the ball not grabbing the magnet strong enough (by getting a magnetic ball) but now have a very loud dragging through the sand problem. I ended up adding WLED on the edges for lighting effects and used it as a college project.

Sisyphus was so cool.

achrn

@Mentaluproar said in SBC mode on non-pi's:

@achrn You're the guy behind Sisyphus?

No no no. I just wrote code that reads the same format files and converts them to the format my table uses.

I built a large rectangular coreXY coffee table that was inspired by that, but I never finished. At the moment, I just solved the ball not grabbing the magnet strong enough (by getting a magnetic ball) but now have a very loud dragging through the sand problem.

I've played with magnetic ball on top in an earlier version but yes get the same dragging noise. I've seen someone advocate a layer of artifial leather fabric under teh sand to mitigate the noise.

A magnmet ball that doesn't roll also grinds down the coating on the ball and then you get a growth of magnetic filings on the ball (at least, I did).

I use a stack of magnets with some really thin ones to fine-tune clearance. I did go through some trial-and-error to get a magnet that worked (ie there were some that didn't). Top of the stack is a N52 grade neodymium 20 dia 10 thick, and stack height is tuned with 0.5mm thick ones in the stack (but I can only get them in N42):

This is not finished, and it's currently on a prototype open bed which is lashed together from off-cuts and bits and even cut up cereal-boxes, but it's about to get built into a round glass-topped table.

Any more probably needs to be moved to an off-topic discussion.

Mentaluproar

I considered attaching a flat magnet to a 3d printed shark fin and letting it cruise around the sand like that, adding felt to the bottom of the magnet to quiet it, but then the sand would need to be even deeper, etc. I think sand tables are beyond my skills. I still haven't planned out out to do designs yet. It's easier for a circle than a rectangle.

@achrn said in SBC mode on non-pi's:

any more probably needs to be moved to an off-topic discussion.

link me there and we'll chat about it sometime. I'd love to be able to finish this thing.

o_lampe

@achrn
NeoPixel control and on_the_fly post-processing are two good arguments for SBC use. I wish, we could also simulate gcode files on the Pi.

[OT]
I had a sand table almost ready to run on my hashPrinter with 4 balls/magnets, but the noise was too disturbing.
I read of people using baking soda or other stuff instead of sand.

re: ball/magnet:

don't use stainless steel balls from ball bearings
build a steel magnet holder with a good flux-return path, it doubles the magnetic force

dc42

@o_lampe said in SBC mode on non-pi's:

NeoPixel control and on_the_fly post-processing are two good arguments for SBC use.

All Duet 3 main boards can control Neopixels.

o_lampe

@dc42
RRF can do basic stuff with NeoPixels, but i've seen 'animations' with colour fading and other beautiful stuff. (campfire or ocean waves)
That's beyond RRFs capability AFAIK. It's overkill for simple 3D printers, but nice to have for sandtables and such.

Mentaluproar

How do I determine the transferreadypin on a lepotato?

chrishamm

@Mentaluproar According to https://docs.google.com/spreadsheets/d/1U3z0Gb8HUEfCIMkvqzmhMpJfzRqjPXq7mFLC-hvbKlE/edit#gid=0 it should be gpiochip1, number 79.

deckingman

@Mentaluproar said in SBC mode on non-pi's:

@achrn You're the guy behind Sisyphus? ...............

Sisyphus was so cool.

For info, the original Sisyphus machine was invented by a guy called Bruce Shapiro. I've seen one of his machines at Questacon in Canberra, Australia which was installed in 2013 but there are others around the world.

Also for info, Sisyphus (or Sisyphos) was a king of Corinth in Greek mythology, who was condemned by Zeus to spend all eternity rolling a boulder up a hill in Hades. Hence the name given to the machines.

Mentaluproar

@chrishamm I'm getting an operation failed error. Failed to open IO device. Error 19. Cannot put line into event mode. I applied the settings you gave me. Seems there's something still amiss here.

chrishamm

@Mentaluproar You probably need to remove the pin from the sysfs interface first by running echo 480 > /sys/class/gpio/unexport as root.

Mentaluproar

@chrishamm said in SBC mode on non-pi's:

echo 480 > /sys/class/gpio/unexport

bash: echo: write error: Invalid argument

My understanding is this has been depreciated so it might not work properly.